Разница между throw и catch весьма существенна: throw - пришел и прошел дальше не задерживаясь, catch - стою, жду. А третьего варианта BPMN не предусматривает.

Семантика intermediate none проста - это веха / milestone / смена статуса процесса. В этом согласны Брюс, Camunda и Tibco. Только Bizagi шагает не в ногу.

Вы правы, группировать процессы по принадлежности к функциональным подразделениям - плохая идея. Кросс-функциональный и сквозной “от и до” - это важнейшие аспекты бизнес-процесса.

As for the Error vs Escalation, I agree on their different End behavior - but isn’t this countering your point in this post that Error and Escalation events are more or less interchangeable?

Thanks for valuable input. We do not necessarily agree but your comments are always thoughts-provoking.

Camunda is great, thanks for another proof.

There is a subtle difference between conditional event and xor gateway: if the condition evaluates to true then the process will continue at the gateway but stop and wait at the event set to the same condition. Most people do not realize this I guess.

As for the error vs. escalation, we discussed it here http://mainthing.ru/item/446/ ages ago ) The difference between error and escalation is that the former behaves like terminator while the latter does not.

I agree that the subprocess workaround does add a load yet it’s more versatile and explicit so it’s worth to come through it once to get more freedom and preciseness.

[I would have argued in the gateway post that inclusive gateway is very useful too and it's not that difficult to explain - it's basically a parallel gateway that passes dark tokens on inactive branches - the scenario of having multiple options activated or not is very common in business and I have not found one single case where this could not be explained to a novice in as short a time as the rest of the gateways]

Several comments on your current post:
- conditional events are not very intuitive, but they could be helpful to model data conditionalities (especially as boundary events). Again, easy to explain (same cognitive load as XOR). BTW, camunda BPM supports conditional events.
- signal events are very helpful as described in your pattern, especially if you need complex orchestration of multiple instances - the downside being the load on the process engine. Messaging is not necessarily a tight coupling and could be a solution to the load problem, especially at scale (volume + velocity of signals event stream interrogations).
- error / escalation - we tend to use them with a touch of style: error is for technical handling, escalation is for business handling
- I found in practice that working around specific exotic events by means of subprocesses actually adds to the cognitive load, because it is less intuitive to discern process and sub-process boundaries and scopes, than deal with the same concepts at activity level.