Considering all the books about state machines I do not think our various short comments will be able to capture the full extent of state machines, their differences, or the every precise terminology as used in their many applications.

My naive understanding is that Moore machines have outputs depending only on state, with the next state depending on current state and inputs. In Mealy machines the outputs both on current state and inputs, and so do the next state. Personally I thought they could be converted back and forth, and the practical reason to choose Moore was more about avoiding electrical glitches when used with hardware. According to Wikipedia though not all Mealy machines can be converted to Moore machines, but I leave that rabbit hole for someone else to drown in.

I’ve mostly used state machines with electronic sensors, buttons, joysticks etc as inputs and controlling motors, relays and UI as outputs. The values of these are variables where the inputs reflect their current state, while for the outputs reflect what state I want them to get to. They are not states in the finite state machine terms, but they are nevertheless stateful variables which together with the FSM state describe the systems overall current state.

I agree different terminology for these different kind of states would be clarifying, and that in this setting states of inputs and outputs would better referred to as just variables. Nevertheless those variables do state though. If I got a latching button that is either on or off then that is holding state, and usually referred to as such. I don’t think you can convince me inputs or outputs do not represent state.

strategy, market_data_source, account_manager — each is a map with a module key and additional context.

I suggest to flatten them into the parent struct, use tuples, or use new structs. A map is a bad choice because with a map I have to write the keys and I will make typos.

trading?, rolling?, portfolio_heat_warned, portfolio_heat_blocked — state machine flags that control what
the GenServer is allowed to do.

Boolean flags are bad choices to encode state machine states (sooner you will find some combinations are illegal). Ideally, they should use enum types but since Elixir does not have a true enum type I’d just use atoms.

Either we call if FSM, or we have flags, tertium non datur. State machine is not an object having state field. There should be a single source of truth and any flags spread the responsibility inevitably resulting in a diverged inconsistent state sooner or later.

FSM has transitions and the transition callback in the only place where the decision might have happened.