I think one key is that in the real world (where these things are plugins/actors) there is there is a distinction between functional and actual immutability. If

I think one key is that in the real world (where these things are plugins/actors) there is there is a distinction between functional and actual immutability. If you need to block a block or undo a change, write a PR to the relatively-frozen codebase of the relevant b-thread/actor, that makes its behavior conditional to a never-before-seen event, but default to old behavior - that way it is verifiably not going to introduce behavior changes on its own, but it makes itself amenable to new extension points. One could even formalize this system: a piece of code can be replaced if its behavior under its current set of events is guaranteed not to change. Also, weighted/ordered behavior is sometimes necessary due to race conditions: two identical threads respond to events in different ways, which one wins? When I have made systems with plugin-like architecture, I always establish a global “pecking order” of sources for consistency, but anything that relies on the pecking order is a massive code smell. (That’s a rule I wish I could tell my younger self to follow more often!) I’ve spoken in another comment about testability: https://news.ycombinator.com/item?id=20562272 https://news.ycombinator.com/item?id=20562272 I love these kinds of magical discussions :)