I can’t speak to this particular implementation but events in a ststaechart are supposed to bubble up

That said, a withdrawFunds action shouldn’t be available if the user is in the loggedOut branch of the statechart

As it happens, the "chain of prototype" implementation definitely ensures that method handlers "bubble up," for example the .close method bubbles up.

I'm wondering if the method should just always exist? If you have a state machine that transitions in response to events, it usually is the case that events can arrive regardless of the current state. So the method should always exist and do something, perhaps report an error.

You might also want to know which actions are valid for UI purposes, but validating an action is more complicated than just checking the current state. For example, a withdrawal action may or may not be valid depending on the amount.

in my finite state machine framework that i built, this is what i do. a state machine is modeled by a class and the states are child classes. for state methods, which are defined by the parent class, i force them to be overridden. then if that method isn’t supported in a certain state, it just does nothing. there is support for sending a return message stating the method sent is not valid in the current state (this is within an actor framework), but i found for the most part doing nothing is fine for most use cases.

Subclassing and returning a new object instead of updating the existing one.

Sometimes that works, but if there is more than one possible next state, you need to return a supertype and you're back where you started.