I follow Bruce Silver’s interpretation:
* orchestration = single pool, sequence flow
* choreography = communication between multiple pools, message flow

BPMN 1.1 spec define choreography as “an ordered sequence of B2B message exchanges”. It’s close to your interpretation because B2B situation implies lesser predictability.

Two interpretations diverge on multi-pool processes with pools representing different process instances, not different business entities. And this is exactly the subject of the original post. Under your interpretation, I should have call it “Single pool end-to-end process”. Not a bad idea may be, thank you for the input.

Of course you diagrammed both choreography and orchestration. The words “branches may go” from your first post are misleading I’m afraid: most people would suppose you mean sequence flow. So it’s my turn to ask you be more accurate

Please be less pedantic Or better ask BPMN standard body to be more precise

Of course production goes after ordering - did I said the contrary here? The question is: whether an order fires production (in that case it may be implemented as a subprocess within the same pool) or production is triggered by some other event e.g. by a timer (then it’s another pool). My point is that novice BPM desingers tend to use former model but the latter is more realistic.

Branches from a parallel gateway may go over other pools? I seriously doubt this. Not in BPMN. But you are right: parallel gateways do produce asynchronous threads.

My favourite analogy to process choreography is threads programming in java.