It sounds like you want to make fundamental changes to the way orders work. The current function of the menu is not consistent with all of your ideas. This is because actions are the fundamental objects of the menu, not buttons.
For our purposes lets say an action is something that attaches a behaviour to LMB. So when you click LMB something will happen (eg, queuing a constructor). Shift, Alt, Ctrl and Space are able to modify the behaviour of LMB as it is pressed. Hacky widgets can make any key modify click behaviour, such as Q for spam nanoframes, but they're messy. I wrote that widget 8 years ago and would do it better now. Finally, some types of actions directly apply an effect without passing through LMB. Some examples are the Self-D and Stop commands as well as all state toggles.
The structure of Spring gives every action the inbuilt ability to be bound to keys. Actions can be bound to combinations of keys, many different keys and you can have keys which toggle actions (so they cycle the behaviour of your mouse). Spring also allows widgets to trigger actions, which is how clicking on the Attack command in the menu makes your LMB attack.
Our ingame settings menu is structured to match the structure of Spring. Actions are the objects, which you can see by binding things through the menu or directly editing zk_keys.lua. There are some hardcoded contexts (such as ZX when placing structures) but no ability to create contexts. You can still do A to attack with the command menu disabled. Even disabling luaUI might still let you A to attack. There are actions which do not exist on the command menu. Basically, the default system of Spring leads to a command menu which is an alternate way of giving orders rather than list of available commands. Viewing the Order tab is not required to give orders that appear there. Currently the tab acts more as a reminder that commands exist and a way to access rare commands.
#1. The ZXCV tabs work by absorbing the keypresses before they reach the action handler. We've reached hacky territory because the grid layout is hardcoded (with a toggle for German keyboards). Every key from Q to N is absorbed by the menu. Ctrl, Shift, Alt and Space send you back to the order menu because you might be pressing Ctrl+C and would not want the C absorbed. I've implemented a naive way of activating hotkeys for tabs. You can see whether it works or whether it causes issues.
#2. The UI should not undergo small size changes depending on what you select. Also, Core Selector would then be left disconnected. The solution is to grey out the empty tabs. I have not received the PR for it yet though.
#3. An option for this is implemented but it conflicts with current hotkeys. Mainly, it means that you can no longer give Fight commands to your factory. Also, it disables Area Guard because that requires a keypress to activate. The Order tab exists but you should never need to select that tab while working with a factory.
Also, for my own hotkeys, I bound Priority to Q. I think Priority should be bound to something so this creates an additional problem. We can also consider binding Repeat by default.
#4. I like how the Factory tab avoids ZXCV and this tab is rarely needed in any case. If we are considering more redesigning then I would move factory to the end and bind it to B. Then Z can be something useful (such as idle worker).
#5. You should never be navigating to or from the Units tab. It also behaves differently to the other tabs, they are exited when an option is selected. Units is not. It could have a hotkey but it may be confusing and I think it would be a waste of space.
