So, if I get it right, this state-machine based code would cause 1 _physics_process's delta delay before user's input will be processed.
For example, character is on the floor and in the idle state. When the user presses a move button, idle state would receive non zero velocity vector from the parent's get_move_direction method. In that case, idle state will call transition to move state. But user's input will not be processed immediately.
Delta in _physics_process is very tiny. But can this delay in input processing affect game feel somehow? It could be that applying players input will be delayed to the next frame.
_physics_process is called, user pressed a button, but we simply call transition to move state and not actually applying this movement
_process is called, frame is rerendered into the screen
_physics_process called again, now the move state applies movement
But we have already missed whole frame!
Maybe it would be great to try another solution:
Definitely, a one-frame delay is a one-frame delay. It can be hard to spot but it'll affect the game.
I have to step through the code and think about it. Maybe calling State.physics_process() directly after calling State.enter() in StateMachine.transition_to() would do the trick.
Thanks for pointing this out.