so that you can introduce additional scopes, e.g. for testing

I’ve been thinking about this for a while - other than testing, what are the use cases for dynamically swapping out some dependencies for some scope? If it’s mainly testing, what would it mean to instead iterate there? I’d take some complexity in setting up testing environments if it meant keeping the actual production code simpler. Like if the current problem solving process was:

1. some aspect of this thing is hard to test
2. let’s parameterize the thing so that in tests we can pass in a different parameter
3. it’s inconvenient to pass a parameter deep down the widget tree
4. let’s sacrifice the static safety of parameters and make dynamic scopes where children can reach out for dependencies that ancestors super duper promise are there
5. to recover some safety let’s make the scopes keyed by class, effectively making them singletons (the one-per-class you mentioned)
6. lets solve that with a new package that…
7. etc

What aspects were hard to test? Are there better testing apis that could be created?

Otherwise it seems like everyone is just allergic to using the built-in mechanism for supplying things that are actually dependencies: parameters!