...

The distinction made between state and state_machine, which I > consider to be unfortunate, was not justified in the rationale...

There is at least one good reason - the library supports both synchronous and asynchronous state machines, which are essentially different beasts and are operated quite differently. No such distinction exists for states, therefore they shouldn't be treated the same way as state machines.

However, asynchronous_state_machine is separated from both state_machine and state. Ergo, the reason must lie elsewhere. I didn't delve deeply into the library's support for asynchronicity, but I did consider it odd and amusing that at the level of hardware circuitry, asynchronous behaviour is the default, and work is done to get synchronous behaviour by adding latches and a clock, but that for fsm (and many, many other software components rather higher-level than a J-K flip-flop) the opposite was true. I do understand it, but I am not convinced that in this case it was the correct decision. Unforunately, I have to leave for work now. :-)

Otherwise you would be able to mix both synchronous and asynchronous states in one machine, which doesn't make sense.

While tangential to my original point about naturally recursive structures, I'll take time out to disagree here too. It _can_ make sense to combine async and sync behaviour in different parts of a state machine when one is modeling electrical circuits, e.g. in certain regions of the circuit one may know that the behaviour is sync and not want to spend extra CPU by going through all the async motions. Dave