Been chatting a bit with Thomas. The part that wasn't clear to me is that the "set of bundles" he describes is really a number of independent deployment units. Any DeploymentUnitProcessor would see each deployment unit as an independent thing. He was seeing a DeploymentPlan as a way of processing them as a unit.
Currently, all the deployments in a plan are installed as part of the same batch. So his ThreadLocal approach lets him use a TL to detect and count up all the deployments in a batch, and then use a listener on each service to track when they are all started, moving on to his #2 step at that point.
We talked about instead adding a notion of a DeploymentSet. All updates associated with a DeploymentPlan would be associated with the same DeploymentSet. The DeploymentSet could be attached to the DeploymentUnitContext for each deployment, and a callback triggered when the update for each deployment in the set has been applied.
This is similar to some things that would happen with ear deployments; it's just that instead of using packaging to determine what comprises a set of deployments, we'd be using the fact that they are in the same DeploymentPlan.
This can use some further digestion, but it's intriguing.