I don't know if I will have time to do a proper review of the library. The following are my notes on it so far. I've read the documentation for the libary, but haven't tried to use it. Good points: Simple. Relatively fast at runtime. Docs are quite good, but perhaps lack enough rationale style documentation on how the library models FSM concepts. Would benefit from some "how to" examples of more realistic usage and some "how to" docs on translating FSMs expressed using UML (or Harel) statecharts into a form implementable using FSM. Bad points: Unusual terminology. While there are obvious performance reasons for avoiding the Boost Statechart approach of applying an RAII model to state activation, it is not clear why at least basic concepts and terminology have not been used in FSM - especially as most Statechart terminology and FSM behavioural concepts are straight from UML terminology (it is a standard, you could pick another one, but why not stick with this one)? Note that this is *not* a request that the library include more features - just for some consistent ones. Some idiosyncratic behaviour. The FSM delivers the event to the on_process() handler in the "switched to" state when the transition is specified using the transition map, while delivering it to the on_process() handler in the current state if no transition map entry matches. There are warnings against mixing the transition map and switch_to() approaches to FSM specification, but even so it seems that the 2 uses of the on_process() handler are completely different. Would it not be better to have a model similar to Boost.Statechart where a custom reaction (implemented by a react() method) in a state is used to perform actions within the start state, generally including making a (gated) transition, while any action to occur on a transition is specified as part of the transition? Further, that transition action should be performed after the exit action of the current state and before the entry action of the new state. No event queuing mechanism, so no way to post an event while processing an event - although I see there has been some discussion about adding event deferral - which might be (almost) enough. Slow at compile time. I have not tested as yet, but if it is as slow as the mpl example state machine implementation, this will be a problem (I have previously had to abandon use of the MPL FSM due to compilation time issues on only moderately complex FSMs). Lacks real world use? I don't know if that is true, but I haven't seen anything other than toy examples. I was thinking that in the cases where the performance of Statechart was inadequate for complex augumented FSM implementation I would consider using FSM - but it would mean building a fair bit of additional scaffolding around FSM - maybe this should be part of the library? Or at least some examples of ideomatic use should be included? I found myself wondering if anyone had actually tried to use it in this way? Conversely, I don't find it compelling for implementing something like a lexer or even the terminal emulator example. What is the application domain? Not quite a conclusion: This is a hard one. At one extreme, Boost.Statechart is extremely powerful and well worth using in certain application domains (but there are performance implications), and at the other, as has been illustrated, various hand-rolled solutions of varying degrees of elegance get the job done. There seems to be a lot of space in between, and I'm not sure that the proposed FSM library fills enough of it.