This is usually modeled better on backend systems (a state while waiting for a network response to arrive) but is often modeled poorly in front-end systems (a state while waiting for an animation to finish).
Operator pushes Start
Turn motor on
Motion triggers switch to ON state
Motion triggers switch to OFF state
Turn motor off
Machine changes state to RUNNING
The time between pushing Start and RUNNING is only a couple seconds, but there's a chance that something could jam, the switches could fail, or something I have no knowledge of could go wrong. Question becomes, do I now need an intermediate "In Motion" state for the six or so cases where this happens?
In the end, I decided no, because there was no other transition out of that state than the expected behaviors, so modeling the intermediate state didn't offer me any benefit[1]. Failure to get to OFF state within a certain time puts the system into a global error condition that required manual intervention to fix.
I don't have a real comment here :-) other than to back up your point that modeling isn't as obvious as it first appears to be.
[1] I would have created this intermediate state if this was a complex controller that was likely to have new rules added later. However, knowing it was a simple one-off, I'd just be giving myself extra work for no benefit if I did it now.
In the example given, I'd probably stick to a single intermediate state and let the language work as my implicit state machine for the internals.
Depends a lot on the boilerplate required to insert states though, my preferences owe a lot to the HFSM implementations I've used in the past.
A lot of people don't even realise they've made a modeling error. Then you invariably see code written to try and handle "unexpected errors".