Some of the special actions available to units is intended to move the positions of other units, either your own or the enemy's. In this example, the Heavy Knight rushs forward two squares and does a spinning grab, causing all units in the neighboring four squares (in this case, two ninjas) to rotate one square clockwise. Having completed his move, he gracefully exits the battlefield to make way for the Gold Knight's charge. Then the Gold Knight is able to rush ahead with mucho power and kill those two ninjas (now in perfect position) and meet the enemy's captain head on.
Each action in the queue takes place sequentially, each action completing before the next one starting. A defending unit does not have a queue and pretty much just sits there and gets hit, except when attacked from the front. In that case, both units proceed in the same order (magic, ranged, then melee) simultaneously. If there is a case of two units entering combat, both using a command queue, each block is taken simultaneously. For instance, if the first block is archers for the defender and knights for the attacker, both will attack at the same time. In the case of speedy units (like thieves), perhaps they have a slight head start or something.
Actions that change formation can only happen at the end of a command queue. You can have several of them (such as changing to a formation and then rotating twice), but they must be the last actions in the queue. If your opponent's queue is longer, it is possible that some of his combat actions may be played out during each formation action. In that case, the combat action launches first and after it is done, then the formation action. They both must play out to completion before moving on, regardless of what sort of actions (if any) follow.
As shown in the previous entry, one designs their own command which they can call later. One could think of these as sub-routines. You could call a command routine from within another command routine (maybe even multiple times). Use it to store part of a command that you'd like to reuse between different commands. Either you could use a naming scheme to indicate incomplete commands, or you could perhaps have the program flag only complete command routines as ones that can be called from the field map.
A routine will basically just insert itself into the command queue as is, such that each block executes as if it were part of the queue. Nothing complicated here.
Let's say you've got this command queue ready to go. It's not very receptive to change. If one of the needed units is dead or otherwise incapacitated, then it continues on (that block is considered a PASS). But if you have a situation where one command depends on another command succeeding, then you've got a problem. That's where conditionals come in. Basically, it's a branching path that branches based on some criteria.
Here, certain blocks are only acted upon if the previous block succeeds (the unit has completed its move like it was supposed to). If the previous block did not succeed, for one reason or another, it skips those three blocks. They are not counted as PASSes but are actually skipped, causing later blocks to act sooner than they would have otherwise. You can use this to your advantage if you need to vary the time before certain actions happen.
Here is an actual branch, with two different sets of blocks to activate depending on the success of the previous block. One could assume that each one of those paths could split as well, but there should be some sort of limit in place for actual branching paths. Perhaps there is a max total limit to the number of blocks you can use, or simply a maximum number of branches possible.
Of course, success isn't the only conditional available. At the very least, there should be basic boolean operations (AND, OR, NOT) so that you can make sure that more than block successfully completed. Also, there should be conditionals for whether or not a unit is still alive and well, whether a wizard is capable of casting a spell this turn, how many enemy units are still alive, and so on. Don't need to make it too complicated, but enough that you can make some fairly important decisions within a command.