One plausible approach: The process model / workflow stepper could just install the new model and replay the events it's already received. They will presumably still have happened, because we're not supposing the past can have altered.
Objection: What if the new version has a different structure in the "past", for the next time it's used, or for the next time around a loop?
Reply: Then I guess we'll need a stack of versions.
Suppose we have a node N with children N.1, N.2, ... and (just as an example) that the N.1 has to execute before its siblings.
There seem to be two different kinds of parent nodes. For one kind, N would be an action in its own right, and when there's complete monitoring (ie, everything that actually happens is known to the monitor), startAction(N) and startAction(N.1) are separate events. (You'd get separate Kqml messages for them, or whatever.)
But "transparent parents" are just groupings of nodes. In this case, startAction(N) and startAction(N.1) are (conceptually) the same event, and we would probably say that startAction(N) isn't something that really happens at all.
More generally, if a node N that has children starts executing, do all initial children (ie children that will execute first) start executing, or do they merely become ready. For transparent nodes, they should start executing; for opaque nodes, they should merely become ready.
The issue also comes up when we try to count the number of nodes that have executed.
In the ACP3 model, it looks like "execute plan-cycle" is pretty transparent (at least translucent), but "create COA" is not.
This creates a great deal of confusion when trying to understand the model, especially when nested loops involve both translucent and opaque nodes, and it makes me wonder whether IDEF models are really well-defined when it comes to saying what events can occur.
The ACP3 Java code treats all nodes as opaque, which doesn't seem to cause any serious problems.