Andreas, I have looked more thoroughly at the fsm library and have this specific problem I would like advice on. The source state (as well as all the rest of the active direct and indirect inner states of the innermost common outer state) is destructed before the transition action runs. This means the actin doesn't have access to any of this context, considerably reducing the utility of state local storage. The stopwatch example shows the storage being used in the exit action, which is fine. A more complex example would be likely to have separate actions for multiple transitions. It seems that if actions need access to the state local storage of a state being left one must do the following: 1) Have states with only one transtion. 2) Be prepared to execute the actual "work" done by the system (the actions) in the exit action (which is a destructor). I don't find either of these attractive. Alternatively, a custom reaction can be used. The react function can do processing in the context of the source state (it is a member of the source state). I'm not sure how easy it is to access other active (inner or outer) states at this point? So I end up with a "pre exit" action. User defined exception handling can be used here (that is, it is possible to: 1) map an exception to an event 2) make (or not) an immediate transtion to an arbitrary state based on an exception 3) terminate 4) let the fsm framework deal with it This seems reasnably ok, but doesn't make for a nice transition table representation (the transition information is "hidden" in the react() function). Another option is: Keep a shared_ptr<my_local_storage> in the state. Construct a my_local_storage in the state constructor. In the react member function, take a copy of teh shared_ptr. This should keep my storage "alive" until the transition is complete and the new state has been entered (actually a bit longer than I would like). Am I missing something or doing something wrong? Can you recommend an approach to deal with this? Thanks Darryl Green.