I don't think that's quite right. In both cases, the logic flow is

1. Receive a request from the browser
2. Decide what do do about it
3. Tell the browser to enter a new state
4. Wait for the next request from the browser

The difference is in the nature of (1) and the details of (2). I prefer to think about it this way:

• C::A wants to know where you want to go, and decides based on that and the data provided where you actually end up.
• C::P wants to know where you were and decides based on the data provided where you actually go next.

For me, apart from style preferences, C::P works well where the validity conditions for entering particular states frequently depend on the current state. C::A is useful where the validity conditions for entering a particular state depend solely on the data requirements of the target state.

If a C::A app always required a parameter for "current state" along with the "run mode" and used that plus other submissions to determine the state entered, it would provide the same functionality as C::P. C::P just enforces that kind of thinking from the beginning.