Currently if guard evaluates to false, when block=true, it will continue
to block until the guard evaluates to true

Although I can see that having the ability to block until a condition
(e.g. OrderValue > 3000) is true is useful - I believe this will make it
harder to infer flow from a CDL document, as the determination of
dependencies between different concurrent threads now becomes more
complex, as the actual nature of the execution of a choreography will be
dependent upon runtime variable values. 

In the most extreme case, you could imagine a choreography having a
single <parallel> construct with 'n' workunits, all having defined
blocking conditions, where the flow is determined only by inferring the
potential links between the cause and effect of activities within the
workunits, that may change values that would then cause other workunits
to become enabled. Although this is not the most likely usage of CDL,
the fact that we provide mechanisms that support this usage means that
we also have to provide model checking to support this - and I think
such uses would lead to a state explosion of possible outcomes, which
would go against the stated aim of making model checking easy. 

I believe the "block until" mechanism is a good implementation technique
for building event based systems - however CDL is a description
language, and I don't think this approach is useful for building a good
description of the interactions between distributed participants.

Regards
Gary and Steve