D2703.

(You are correct in flagging this as a concern here since I changed behavior of the GUI and didn't check the effects on simulation.
I would like to add that the GUI is only one way to send simulation orders, modders can change it, and one can send them using F9 -> Engine.PostNetworkCommand too)

The reason why I raised the concern was that it was to be fixed and I was too lazy to make the diff. But I only retained that lazyness for about five minutes, though. I have no interest in blaming or shaming, shizzle happens, especially on large rewrites. (Doesn't mean one should commit broken or inproperly tested code, though, just that things might slip through.)

Can you elaborate on the second statement, please? Is it you want to say that PetraAI should handle these cases more gracefully, as proposed in the diff? Or is there something else you want to convey here?

Just wanted to say that simulation code that processes client data should consider what malicious or defect clients could send (never trust the client, https://en.wikipedia.org/wiki/Defensive_programming). There have been various fixes for developer-debugging commands and GUI-trusting simulation commands that could result in players receiving indefinite resources (NaN batch train count), exiting the program for everyone (simulation command, see Commands.js history), colorizing buildings (Commands.js history), sending chat in the name of other players (Commands.js chat command), or ordering spies for enemy players (see spies commit). So I mention it so that it can be kept in mind whenever writing simulation processing commands. I don't know if there are oversights in the proposed patch, but sometimes one can construct some by reading the code and trying to invalidate its assumptions.