It's for cases like this, really

    if (jumping) {
        FSM.changeState(new JumpState());
    }
    if (running) {
        FSM.changeState(new RunState());
    }

If the user doesn't stop the function call with a return after calling the changeState, there are times when the FSM changes into a jump state and run state in the same call. Without locking it to one change per update, it would be the running state that would become active after the jump state has. Locking operates on the presumption that the of the order of the states loosely correlates to their priority over one another, so it likes to stick with the first it receives. You can override this with force if need be.

One option I considered was having the enter/update calls have a return of Null<IFlxFSMState<T>>, where if you wanted to change the state, you returned it. Clean, but perhaps somewhat counter-intuitive, and there's some form of overhead for processing null types.