In 4.4, the implementation of the ForkActivity was changed such that a map (Transition -> Child Execution) is now built. Because this is just a generic map without any ordering, the actual order in which the child executions get executed is now non-deterministic. In 4.3, the order was always the same as the order in which the outgoing transitions were listed in the process definition.

Now, I'm not sure if this side-effect (making the order non-deterministic) was intentional or not but it definitely break things when other parts of the workflow rely upon a specific ordering. There are definite, real use cases where it is necessary and desirable to specify an explicit order for things.

Our workaround was to create a custom activity that is basically exactly the same as ForkActivity, but orders the taking of transitions on child executions so that it is the same as defined in the process definition.