I like using FSMs in my apps. However, what I've always felt that they miss is a good way to deal with undefined events for certain states.

Let's take a look at your example FSM: there is no 'take train' event for the 'bed' state. However, while we're in the bed state, nothing prevents us from dispatching a 'take train' event to the state machine while it is in the 'bed' state. What will happen then? If I'm not mistaken, this Tinder library just ignores the incorrect event and no state transition happens. But do we want that?

More formally an issue is: why can we pass that invalid event to the state machine in the first place, while it is in a state that doesn't support the event?

Here is where we enter a vicious circle: the current state defines the events that are available, but entities other than the FSM generate events that depend on the FSM being in a certain state. So, to know what events can be dispatched, you must know the current state! But only the FSM knows the current state: other entities should not keep track of the last state they read from the FSM: that would mean there's multiple places where the FSM's state lives. ... And so on, and so on.

At the end of the day: only the FSM holds state, only external classes generate events that may or may not be defined for the current state.

You might argue (for your example): but how could you 'take the train' while in the 'bed' state? That could happen when multiple asynchronous event generators are at play. Say you're loading an image (takes time, let's do this asynchronously) and the user can cancel the loading operation, or just wait and do nothing until the image is loaded. What happens if the user cancels the loading operation, but just before that event is dispatched to the FSM, the image loading completes and there's nothing to be cancelled? How do we formally handle this cancel event? Do we ignore it? Do we throw an exception and maybe even crash the app? Can we do something else? Or, the other way around: what if the user cancels the loading successfully, but just when the FSM is in the cancelled state, the image is loaded and the image loader dispatches an 'image loaded' event to the FSM?

So, bottom line: always also think about asynchronous event generators and don't forget to define what happens on invalid events! Invalid can be ignored, but you can also throw an exception or move to an error super state (e.g. when using a composite FSM). There's multiple ways to handle invalid events: just don't forget about them.