Has the following scenario been considered regarding 'sub processes'?
A business receives an order for complex services (say telephony. ahem). One or more of the services on the order may require that a technician visit the customer's premise. If a local installation is required by more than one service on the order, the business wants to send out a technician to the customer only once to perform all necessary work.
Each type of complex service has its own ProcessDefinition, and consequently, its own ProcessInstance. The actuall field installation (which includes things like scheduling a contractor, confirming with the customer, followups, etc) is also its own unique process. Each service process that requires field installation becomes one of multiple PARENTS to a single "field installation" process.
The Parents all share a single sub-process and none can continue until that sub-process is complete. Furthermore, if one of the services fails to install on the technician's visit, that Parent process may need to be disassociated from the existing install sub-process and reassociated with a new sub-process instance for installation later.
So...I have to build this--not a problem--I can do it with LOTS of ActionHandler, but so much necessary support plumbing is already present in the current <process-state> implementation.
Are we interested in extending a process instance to be able to have multiple superprocesstokens? If so, I've got a few more thoughts.