[Rumudiez]

You missed the point where a program can take inputs over time. In your example, the program takes “step forward” and goes through the flows, eventually mutating state at the end, including redrawing the screen or prompting the user for their next input. The next input is based on the current state of the machine, and there can be as many or few valid state transitions as you, the programmer, would like to manage.

[Someone]

What you propose requires some arrow leading (directly or indirectly) from mutate! to input. The model I commented on:

  input -> fn1 -> fn2 -> fnn -> mutate!

doesn’t have such a loop.