This would deprecate or eliminate support for attaching things directly to Y.mojito.xxx. Expect downstream breakages.
Wouldn't this be contrary to the way YUI modules are usually authored?
We're already subverting that by storing them in our own container and requiring that they be added to that container. In my mind, Mojito is a framework that should allow adding special types of modules (controllers, binders, etc.) just like YUI does. Either that or not store them in a container and just instantiate them based on class name regardless of their namespace.
I'm curious what you envision this interface looking like, and how it would be fundamentally different than placing constructor functions on some namespace.
It is not fundamentally different from using namespaces explicitly, but it gives us more control over this namespace. We've already had to have BC breaks because the namespacing was incorrect in our archetypes and examples, and I'd like to prevent this from happening again (except this one more time to use the API).
This may change depending on how the YAF integration works (whether if it even uses the controllers, binders, models namespaces), but if we have a hard expectation of where a developer's objects need to be stored, we should abstract it out.