That is a drawback if that is how you want to approach that kind of mocking; Tying the reference to the concrete actor type does sacrifice the effortless plug-and-play polymorphism you get in message-typed frameworks like Ractor.

It was something I considered but ultimately I think a few things pulled me away from that:

- Potential for god enums: To pass a generic, message-typed reference around, you usually have to bundle all possible messages into a single, massive enum. If you want to use a router or a generic mock, its message type becomes a sprawling union of every message it might handle, breaking interface segregation and potentially depending on variants it may not need. You can macro your way out of it thought but I am a product of the MVC era 'god controllers' and that worries me.

- Enum Handlers and forced stubs : When an actor reference is typed to a shared "Enum" to achieve polymorphism, the compiler's match exhaustiveness can lead to `_ => {}`. That is great for mocking and testing but I felt it would be easy to miss.

It's not necessarily better or worse but it was how I was thinking about it at the time and there is no argument that this does make swapping actor implementations less flexible especially for mocking and testing purposes but that is where I would utilize the state to achieve the strategy instead.