I have spent almost an hour debugging the following issue. I have a "main" orthogonal region with a couple of states and an "error" region with RUNNING and PAUSED states, like this: struct PAUSED : public msm::front::interrupt_state<new_job> {}; struct RUNNING : public msm::front::state<> {}; There are transitions PAUSED --new_job--> RUNNING and RUNNING --failed--> PAUSED. Then, in one of the main states, I have struct MAIN_STATE1 : public msm::front::state<> { template<typename Event, typename FSM> void operator()(const Event& e, FSM& fsm) { if (error_condition) fsm.process_event(failed{}); } } and in the FSM I have using initial_state = mpl::vector<MAIN_STATE0, PAUSED>; Now, when new_job is processed and MAIN_STATE1::on_entry called, the machine is in (MAIN_STATE1, PAUSED). In this state, process_event(failed{}) is ignored and not queued because PAUSED is interrupt state. Then, the next orthogonal region is processed and the machine goes into (MAIN_STATE1, RUNNING), which destroys the rest of the logic around which the FSM is designed... Adding using active_state_switch_policy = msm::active_state_switch_after_exit; to the machine did not help in any way. Reordering the states in initial_state fixed the problem, but this is a rather unsatisfactory fix because it doesn't solve the underlying problem of transition atomicity. This is counter-intuitive, being on the border between a bug and lack of clear documentation. Specifically: 1. State switch should be atomic. By using active state switch after exit, I had *expected* that first all exit handlers of the current state are called, the state is atomically switched to the new state, and then all entry handlers are called. What I have *observed* is that on_entry handler of a state in one orthogonal region is called before the other orthogonal region has switched *its* state. Thus, with orthogonal regions, the machine can be in an "impossible" intermediate combination of states. Because not all side-effects have run, this has consequences for all actions/guards acting on state or FSM data, which is illustrated by the following: 2. process_event eagerly evaluates is_event_handling_blocked_helper for each orthogonal region in order. The event should be queued unconditionally, and only after the transition has completed, the machine should dequeue events and check whether processing is blocked etc. This, I think, would make at least process_event to appear atomic wrt state switch. Which leads me to conclude that MSM is seductively declarative on the surface, but that it's rather tricky operationally.