Unfortunately, the original thread on this subject has led to so many side arguments that IMO the main point hasn't gotten the attention it deserves. I'll therefore try to summarize the main point here, so that hopefully a more focused discussion results. State machine behavioral standards like e.g. Harel & UML allow that transitions can cross state boundaries. One example for when this is beneficial is given in Fig. 8 of Harel's paper, which can be found here: <http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Statecharts.pdf> In this example, the main reason for the existence of the "alarms-beep" composite state is to avoid duplicating the two transitions triggered by the "any button pressed" and "30 sec in alarms-beep" events. The design of Boost.Msm and the arguments presented in the thread titled "New library in Vault: Msm (Meta State Machine)" seem to amount to the following claim: It is *invariably* bad practice to let transitions cross state boundaries. It follows that a state machine like the one shown in Fig. 8 should *always* be redesigned so that the transitions no longer need to cross state boundaries [1]. For Fig. 8, I claim that any such redesign will lead to information duplication in the diagram and the code implementing it. Moreover, it's probably safe to say that the ultimate bad practice in software engineering is expressing the same piece of information more often in the code than minimally required by the language [2]. Therefore, if following a best practice leads to code duplication then common sense would mandate to choose the lesser of the two evils. So, boundary-crossing transitions cannot always be avoided. Therefore, the challenge is to show that my claim for Fig. 8 is wrong by coming up with an alternative state machine design with the same observable behavior where transitions no longer cross state boundaries without duplicating anything (transitions, events, states) [3]. Note that the leaf-state in which the machine currently resides is part of the observable behavior. So any redesign must have at least the states "alarm 1 beeps", "alarm 2 beeps", "both beep" and "displays". Anything else can be changed to suit. Note that Fig. 8 shows just one widely used pattern that employs boundary-crossing transitions. Other patterns employ them as well. So, even if Fig. 8 can be redesigned without boundary-crossing transitions and without duplicating any information then this is just one data point. Suitable redesigns for the other patterns would have to be shown as well. [1] UML's entry & exit points are "just" encapsulation tools that allow the designer of a composite state to only expose the parts of the inner workings that must be visible from the outside world. So, a transition destined to an entry point does in fact still cross the state boundary. The same goes for a transition originating at an exit point. [2] Of course, all rules come with exceptions: In some cases code duplication can increase performance, which in turn might help to meet system requirements that otherwise couldn't be met. Under such circumstances of course the lesser evil is the code duplication. [3] The obvious solution of moving the "displays" state into the "alarms-beep" state just replaces the crossings of the transitions triggered by the "T hits ..." events with the crossings of the transitions triggered by the "any button pressed" and the "30 sec in alarms-beep" events. Depending on how the latter transitions are drawn, the crossings might not be visible graphically but on the conceptual level they still exist. This is why such transitions are often drawn as the one triggered by y shown in Figure 2 here: <http://www.codeproject.com/KB/cpp/Statechart.aspx> -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.