BPMN 2.0 is a couple weeks away from its equivalent of "code freeze" and all of a sudden there is this tidal wave of commentary on OMG's BMI list expressing "shock" over the fact that BPMN 2.0 describes processes from the perspective of a process orchestration engine. I haven't heard such feigned surprise and indignation since Congress "discovered" the AIG bonuses. I mean, the hidden underlying pretense of a virtual orchestration engine (if not an actual one) has been baked into BPMN since v1.0. Until now, nobody cared because tools just used the parts of BPMN visible in the diagram - the abstract flow modeling piece - and universally ignored the execution-related attributes. But now with BPMN 2.0, Oracle has flatly said (and IBM has hinted) that this will be their new executable process design language. So the connection between BPMN and execution engines is starting to sink in, apparently.
As BPMS Watch readers know, I mostly agree with the howlers that BPMN 2.0 ignores the needs of business-level modeling. (I had to personally lobby an executive at one of the Big 3 just to get the team to consider my complaint that models lacking specification of data interfaces, WSDL operation and message references were schema-invalid. Now they're not, but it took 3 months of repeated pushing...) So yes, this bias is a problem. BPMN 2.0 could have done more to distinguish between diagrams with lax semantics, appropriate for some business-level models, and those with precise semantics, such as required for execution. But that was never a goal, and this fact has been visible (to OMG members at least) for 6 months or more.
Now it's too late for this outrage, faux or genuine. In any event, it's not a big deal. BPMN 2.0 will be handled by business-oriented process modelers in exactly the same way BPMN 1.x was... by ignoring the semantic details when they get in the way. At least the diagrams will be schema-valid!