...

I ended up implementing timeout support with a WM_TIMER handler in the parent of the state machine class. ...

Does the WM_TIMER handler really add the event to the queue of the state_machine subclass object? If so, then you might have introduced a race condition. WM_TIMER handlers are called in a dedicated thread, right?

From my understanding of the documentation of SetTimer and my use of it, everything should be working from the same thread (WM_TIMER messages are posted to the main thread's message queue, where they are processed while the thread is idle). So, I don't think there's a race condition.

...

Also, like the Camera example, I implemented a post_event in the constructor/entry of some states, which also requires derivation from state,

Correct.

...

and awkward instancing of the event.

I don't understand. You mean the special constructor you have to add to the state, right?

Well, that, but more importantly, the cast inside of the post_event. Making calls to post_event from a constructor/enter seem like a fairly typical use case.

...

Would using methods (Entry/Exit) instead of the constructor/destructor ease some of these problems?

This is a somewhat controversical topic. During formal review there were a few people who favored entry() and exit() functions over the current ctor/dtor design.

Thanks for the explanation (removed for brevity), and the sample code!