I haven't tackled the inexperienced fleet penalties yet, so I will bear this in mind when I do. There are some complexities though. Not all orders involve direction and the ship should only stop anyway if you remove the existing order and give a new one. Some form of abandon current order and move to next might be an option (with a delay) but the issue is that the second order may not make sense unless the first is completed. Another option may be that the crew operates on its own initiative until it responds to an order (moving away or toward the enemy depending on morale). In general though Aurora ships all stop when completing their orders list as it would not make sense for them to continue in the same direction.
For the sake of argument, assume the order delay is 30s in the discussion below.
I think the idea here is that when an "interrupt order" is given (where any order that will happen in the next 30s is deleted) the current order queue continues for 30s, at which point Aurora changes the queue to put the new order first. To put it a different way, Aurora would save and continue executing the old queue for 30s, then an interrupt would happen and the old queue would be thrown away and Aurora would start executing the new queue. If the new queue didn't make sense, the TG would stop and do nothing (or try to execute the next order in the new queue until it ran out too), representing command confusion. If one were going to be complete about it, there would actually be a queue of queues to represent "order, counter-order, dis-order": if a player gave an interrupt order at time=0, then gave another at time=10s and another at time=15s, there would be 4 queues instantiated at time=20s (the original plus 3 interrupts) and interrupts would happen at time=30s, 40s, and 45s. Obviously there would be no delay for orders that were planned ahead.
The main reason I'm posting this, however, is that I realized that the above could be generalized in the game mechanics to a general "time delay" mechanism. One of the things I REALLY liked about SA was the ability to send myself a message with a delay of N turns. If the Aurora code had infrastructure to manage delayed events, there are probably other places where it would be useful, e.g. speed of light detection and/or weapons' fire at > 5 light-seconds. At the very least, it would be great to be able to send myself a message that would show up in a week (the old SA functionality)
John