In BPMN (or any orchestration language), an instance of the process represents one "thing." But sometimes that one thing splits into N independent instances of some subprocess, or you may have N instances that are collected at some point into a batch - 1 thing - that continues from there. In the ITIL Change Management process, a request for change (RFC) can represent either a Business RFC or a Technical RFC. A Business RFC is ultimately resolved into a set of Technical RFCs that must be implemented and tested before being deployed in the Release process. In other words, if an instance of the Change Management process represents a Businesss RFC, that instance splits into N instances of the same Change Management process for a Technical RFC. (You could simplify this by saying Change Management for a Business RFC is a different process than for a Technical RFC, but that's not how ITIL - or perhaps just my correspondent's company - has modeled it.)
The resulting diagram is shown here. A couple things are worthy of note here. One is the use of paired message events (send and receive) to communicate with both the Release process (not shown here) and other instances of the Change Management process. The pairing is indicated by the label of the event. For example, the trigger for the Change Management process is an RFC event. But note in the ForEach subprocess, each instance of this multi-instance subprocess generates an RFC event, so this model is actually recursive! Also, the end event for the Change Management process is RFC Status, and each instance of the ForEach subprocess waits for the RFC Status event for the Change Management instance that subprocess instance started. It makes your head spin a bit, but it works.
In a choreography diagram, you could actually draw 2 pools of Change Management, I guess, showing the message flows between them represented by these paired events.
The second interesting thing (to me) is the use of the multi-instance subprocess to solve the 1:N problem. In BPMN, an activity (task or subprocess) can optionally be defined as a simple (While) loop, a multi-instance (ForEach) sequential loop, or a multi-instance (ForEach) parallel loop. The last of these is what is indicated here by the parallel bars (VCR "pause" symbol) at the bottom of the activity. It means generate N instances of this subprocess, and the activity is not complete until all N instances complete. In this case each instance represents a Technical RFC generated from a Business RFC, and the subprocess spawns a new instance of Change Management for the Technical RFC and waits for RFC Status.
Note, by convention I only use a message intermediate event in sequence flow to mean "wait for the event" - the BPMN spec also allows it to be used as "send the event", but I prefer to use a Send task for that. In this diagram, to make the event pairings clearer, the Send task is followed by a message end event in parallel with the continuation sequence flow.
For my BPMN training I am beginning to think of a number of these batching/debatching patterns and how to model them properly in the notation. Now if I can only get my simulation engine to work with it...