No compromises, please 
You wish : )
I did spend more time on all this trial and error than I intended, and at last I started to think more in the lines of "time's up" and concentrated more on trying to make it playable rather than keeping it as a mockup while I have cut the time I spend on scripting it.
The compromises are certainly not for heck of it, but sometimes due to the extensive time it would take to improve those issues, or even more often, they are compromises between two evils, including the script getting messy with extensive band-aids.
And, I was finding some hints that the C code might be a little bit like a can of worms, like why are some confunc called twice, e.g. like hudselect?
Band-aided some of the clearer and simpler cases like hudselect, but not quite the more vague cases like reactionfire_updated.
And on top of that, it seems like the game would like reactionfire_updated to be in some opened windows, and on top of the top of that, I don't seem to be able to override firemode_listener in a subclass.
And the loopy confunc make me suspect those might be band-aid solutions to things that might be resolved with some analysis.
As for problems that originate from the C code, there's a few seconds of video about my attitude towards those:
It's in the Code.
I have attached the playable version and a screenshot in the first post now (the green dots on the ground can be turned on and off by right clicking the mutant goggles/level button).
The cosmetic glitches do not seem to be disturbing, but I do think the reaction fire associated glitches should have higher priority than, say, the glitches that could be solved by using cvarlistener.
And, I would rather remove another click from the use case of removing an item from hand by arranging the hands as:
actions (mouseover, wheel, RMB for shooting)
-hand container (wheel, RMB for shooting)
-selected firemode label (ghost)
This is because, as I now understand, if mouse is over the hand container, then mouse is also over the node that contains the hand container.
And RMB is available for use on hand container, and a click does not really need to be a click, but it is actually a press.
So the RMB on belt/holster would be unnecessary for removing an item from hand, and there could perhaps be some space for a reload button in addition to reaction fire button.
On the other hand, I find clicking the reaction fire button inconvenient, and would prefer RMB anywhere instead.
And yet on the third hand, in combination with wheeling, RMB for shooting seems better, and it might be better to enforce that habit by removing the duplicate LMB for shooting.
As you can see, there is some unresolved design confusion.
The part that I rather like and might suggest to reuse is the team panel and active soldier, it seems to work fine and I didn't need to band-aid anything there.
Didn't test with 16 soldiers though, but I guess it would work (team panel will be re-sized upwards).
