Marvin writes:

RequestActivityStateChange: I believe this operation will pose challenges in an extensible design.  The current design 
is imperative by nature: it specifies an explicit state to move an activity to.  However, a client who does not know of 
all the extensions that a BES service implements may not know how to pick the appropriate state to transition to.  It 
seems better to introduce a more declarative approach in which clients specify “actions” they wish to occur, such as 
‘CancelActivity’.  This approach would allow the BES service to make the appropriate state transition in response to a
 desired action requested by a client.

This has been discussed before, but with the changes in the state model, it is probably worth revisiting.