This is my first time reviewing a Boost submission, so I'll do my best :) First of all, I'm not going to compare MSM to StateChart for two reasons: 1) I haven't used StateChart 2) I see them both as being individually useful, even if they can solve some of the same problems. Is there not overlapping functionality in many STL containers? Still, they're all well-suited to particular problems. - What is your evaluation of the design? I have been using MSM on and off since January 2009 and have seen the design evolve as new features were added. I first used it in a simple iPhone game which required a way to "update" an FSM's current state. This feature was generalized into the current ability to "visit" the current state. The more I used the library and communicated with the author, it became clear that the design, and any changes to it, were thoroughly thought-out. I especially like the clarity with which one defines an FSM (specifically the transition table). The fact that a single instance of each state is default-constructed and bound to the FSM's lifetime is something that should be carefully considered when deciding if MSM fits with a particular use-case. It was suggested in another review thread that a mechanism to optionally pass prototypical states in to a new FSM be added so that states didn't have to be default-constructible. I agree with this suggestion. Aside from that, the design has made it intuitive to accomplish everything I've tried to do with MSM. - What is your evaluation of the implementation? I've only looked at the implementation a few times over the last year when trying to track down apparent bugs (which were all promptly fixed). Aside from those instances, I try to avoid looking at things that hurt my brain. I've seen the code in "C++ Template Metaprogramming" that MSM is based on, and consider it sound. Is there a test suite for MSM? Do these tests pass on all platforms officially supported by Boost? - What is your evaluation of the documentation? The documentation was invaluable when I was first playing around with MSM. The examples are concise and clearly demonstrate what they are meant to. I would prefer that the documentation be broken into multiple pages similar to other released libraries. - What is your evaluation of the potential usefulness of the library? I think MSM is useful because I have found uses for it. My only significant experience with MSM has been in mobile game development, and I have used MSM in one shipped iPhone game. It has worked very well in particular situations, such as simple AI for a single game entity. The "staticness" of an MSM FSM is advantageous in this example, since constantly creating and destroying states can noticeably affect performance when a large number of entities are present in a simulation. Conversely, I wouldn't use MSM to control the high-level application flow of a game. I've found that the persisted states and default-constructibility requirement end up being hoops to jump through that just aren't worth it in this case where state transition speed isn't a concern. Long compile times in the name of run-time performance have never bothered me either. I can always upgrade my development machine, but a customer can't upgrade their iPhone. - Did you try to use the library? With what compiler? Yes. I've used MSM with MSVC9 and GCC compiling for the iPhone. - Did you have any problems? I've found a bug or two when using MSM, but they were always fixed promptly and correctly. There is of course the transition table size limitation imposed by mpl::vector and the compiler. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've used an earlier version of the library in a shipped product, and I've played with recent versions prior to the review. - Are you knowledgeable about the problem domain? I understand how FSMs work and what they can be used for. - Do you think the library should be accepted as a Boost library? Yes, I absolutely think MSM should be accepted into Boost, and will continue to use it regardless of the review results. I would like to see the documentation restructured and the default-constructibility requirement for states removed via the means already described. My vote for acceptance is not contingent on these requests.