Stack-based state machine
Good stuff, I particularly like State being a purely abstract interface, that's exactly how to best do modern inheritance.

State needs a virtual destructor

This is 100% required in this case, since you delete states from pointers of State.

Reduce API surface

You have too many push_state() functions

void push_state(const StateRef&amp; state);
void push_state(State* state);

template&lt;class T&gt;
void push_state();


You would be better off having just the single:

void push_state(const StateRef&amp; state);


What looks like "convenience" to you just ends up being "confusing" for possible users of the class as they have to wonder "which one of these should I be using?"

Take objects by value if you are taking ownership

void push_state(const StateRef&amp; state);


should be:

void push_state(StateRef state);


Your function currently will always go through a copy-constructor, and for shared_ptr&lt;&gt; this is definitely non-trivial as that has to be thread safe. 

By taking the StateRef by value, this gives users control over whether to provide a RValue, move in a LValue, or provide a copy of some other object. Maximum flexibility without any overloads.

This brings us to:

Prefer unique_ptr over shared_ptr

I see no shared ownership scemantics here, unique_ptr would be better simply for performance reasons. But you may have other parts of the larger codebase that warrant it. That comment is just about the code I see in isolation.

That's pretty much all I've got here.