There is a CommandChanged group EH, but that only works for commands, which is unfortunate when lots of things just aren't commands, see below.

The AI command system is VERY old and messy and I don't understand it. So any more features to it is unlikely.
I found where the UI commands are handled. Its a giant switch case, for ALL hardcoded menu commands (Set combat mode to stealth, take backpack, open inventory, keep depth relative up, slingload cargo, change voice chat channel to global, change voice chat channel to side, set voice chat channel to command, high command, assemble weapon, heal self, open parachute)
There is AI commands, and non-AI actions, all mixed together. Some AI commands are implemented directly in this several thousand lines block of mess (not dispatching any commands, but directly setting flags on the AI group).
It is not feasible to clean it all up in a way where we could decide between AI command or not to give a group eventhandler (or even decide which group is meant in some weird case of File formation, where that is apparently special somehow).
(Why the heck is most of AI commanding, implemented in our Menu UI code, and not in the AI code.. ahhh)

I could make a global eventhandler, that gets all commands selected in UI (Both AI Commanding, and normal action menu).
It seems VBS once had such a eventhandler for the whole menu. It had the command (as integer) and the list of selected units.
The command integer is not guaranteed to be stable though, if a new command is added somewhere it would change (though we likely won't do that anymore), and converting to string is not feasible.

_issuer would always be focusOn and I think for _type I could give you the "name" (config classname?) of the parent menu that contained the used menu item.

Intercepting and returning a different command code, would be possible.
I am also not able to provide any list or documentation of which command code corresponds to what command/menuitem.

@dedmen thanks a lot for looking into it and sorry for the belated response!

It sounds very good to me on what you think feasible all things considered.
Especially if action menu could be intercepted and handled too!

If the event would only trigger locally (which is likely how it works I'd assume), _issuer would be always the player - i guess focusOn would be that?

The community can determine the id to command mapping by trial-and-error. Shouldnt be too hard.
Especially if parent menu means the menu context the command is issued from - reduces the options a good deal.

In regards to simple (old OFP command list based menu)/complex command menu (3d context specific) - is there no distinction, or handled on a higher level already with the underlying system using the same base then?

The command integer is not guaranteed to be stable though, if a new command is added somewhere it would change (though we likely won't do that anymore), and converting to string is not feasible.

Seems acceptable to me. Even if it would change, would be only low effort to adjust the scripted system.