Completely disagree with the title. A system - especially software - can return to the same state at a later time. It makes no sense to conflate the two. It's

Completely disagree with the title. A system - especially software - can return to the same state at a later time. It makes no sense to conflate the two. It's telling that the author deliberately starts with a clock as an example - something whose state is supposed to reflect time. The main point seems to be one about hidden state or unobservable internal state, and I'm all in favor of having that. One of my preferred ways to make software subsystems (particularly in embedded devices) is to use a state machine. To the outside software there may be only a handful of visible states - NOT_READY, READY, MODE1, MODE2, MODE3, FAULTED. But internally there may be any number of intermediate states - several startup states hidden behind NOT_READY, several transitional steps in mode changes, etc. When switching modes I prefer to report the old mode until a transition is complete and then show the new mode as the current state to the outside world. IMHO you don't want to report "in transition" or anything like that, the outside may need to tolerate some time going by before getting what it wants, but it's not needed to know what's happening internally. You either get there or fault. The simplification from what's happening to what's reported is important to reduce the spread of complexity.