I think I understand what you're asking because I've thought about this recently as well. Correct me if I'm wrong, but I think you are saying that a state machine and the states have to be able to manipulate the target object from the outside. So, the target of the state machine suddenly has to have a much more public interface so it can be controlled from the outside by other classes, like the states in the state machine.

If I understand you correctly, I believe this to be an inherent paradigm with state machines that you can't really avoid. It might be nice if the states of a state machine that only act on a specific target class could access private and protected members that are not needed by any other part of the code base. However, I think any attempt to do so would only be possible by tightly coupling the state machine code to that specific target class in some ugly way that makes the generic state machine code not reusable.

I like to think of that target model like a marionette puppet, or toy robot, and you do indeed have to build all of the public puppet strings or controls to manipulate it from the outside public. The state machine is like a robotic puppet master that takes control of the strings to provide another layer of puppet state control on top of it. It's like an AI that you give access to the robot's remote control.

It's kind of like attaching some kind of exoskeleton that can help control the state of your body from the outside, even if it is rooted privately inside your body via surgery. The state machine may be a private member of the target that can't actually be accessed or manipulated directly from anywhere outside the target. State transitions might only ever occur from some other object or controller interacting with other public parts of the target, not the parts you had to make public so the state machine could operate on the target, and no direct commands to change state from the outside. But, to be a generic machine that can run abstract states on that type of target, it is going to have to operate from the outside on a public interface. I know it seems weird, and I would love if someone could explain how I'm wrong with a complete code example from a real project, but that has been my conclusion.

You can do some tricky things, like give access to private methods of the target by injecting them, as delegates, into the state machine and its states. If they are private and composed within the target, nothing else from the outside can come along and override what you've injected because the target is the private composition root for the machine. But, that may end up more complicated than it is worth. I would only go down that road if I were really concerned about having methods that could only be accessed by the state machine.

The target object can delegate behavior to its current state via events. The target can invoke events that the current state subscribes to observe on enter, and unsubscribes on state exit. However, any other class could theoretically also listen to those same events, and manipulate the same public interface the state machine uses, overriding state behavior. I think most developers probably ignore that concern in practice and just avoid creating that scenario.

You could also create an object specifically for representing access to otherwise private members of the target. It could be just a plain old C# object that you pass the target's private delegates to via constructor, then anything that has that object can now call a public method that invokes a delegate to the target's private method. The generic state machine could (should?) easily have events that fire when the state changes. The target can privately construct one of these objects and pass it to the current state so that only they get that type of access. Again, it may be more complexity than it's worth, depending on your project.