The reactivation would have to check if there is another subsription for the start message present, and either disallow the reactivation or register for the start event again.
My motivation was that deactivating process instances could provide an easy solution to a deployment problem we were experiencing. An example scenario was that we had 2 process definitions, named "1" and "2" for the example. Definition 1 uses a message "A" as start event and definition 2 a message "B". Now, we wanted to deploy a new set of process definitions, where now definition 1 uses message "B" to start, and definition 2 uses something else. If now definition 1 gets processed first during the deployment, deployment will fail, as the current state is that definition 2 starts on message B.
Of cause, this looks easily solvable for 2 process definitions, but as our application uses a set of 20-30 process definitions, manually figuring out a working deployment order is not going to work. Deleting deployments is also not an option, as we need the history.
We have currently implemented a solution that deactivates the old definitions and removes their subscriptions manually, the main intent behind creating this topic was to find out if keeping the subscriptions for deactivated process definitions was done intentionally, or if we should provide a pull request to change that behaviour.
