Hi David,

It is sad that my comments are construed as criticism of MSM, since they merely point out the (I thought obvious...) similarities with another library already in Boost. After having tried MSM for a few days, most of it rocks, and I will provide a review later today.

Oh I didn't take it as a criticism of MSM at all, merely of a valid issue which will have to be solved in Boost at some point because, as Boost grows, it is bound to happen again. I'll look at your review with great interest and thank you for taking the time to write it. To the core of your point, which is actually a valid concern. I agree that MSM and Statechart are solving the same problem. To explain what I (and probably Andreas) mean, let's look at the problem from a different angle. Let's suppose we'd build a Statechart 2.0. How would it look like? Would it go for the MSM way, putting as much as possible on the compiler, at the risk of breaking it, or the Statechart way, less metaprogramming and easier on compilers but slowlier and with a less descriptive interface (in my opinion)? Would it go for a transition table way or a state::react way? What kind of state storage would it take? And so on and so on. What is likely is that we'd probably not even manage to agree on the goals, much less on the design or the implementation. MSM comes from my frustration with not managing to make Satechart do what I needed. This shows that the philosophy of both authors is quite different and likely incompatible. Christophe