I don't think I like the idea of a bean going directly into the registry.
Although it is certainly possible to implement it that way with the new
container, you lose some features.

(This is one of the problems with the current JMX micro kernel where MBeans
that do not go through the ServiceController cannot take part in the service lifecyle/dependencies).

With the new container, the beans can take part in dependency injection
on other objects, but there is nothing to say that that bean's dependencies
can be satisifed in a hot deployment environment.

In general it bypasses the controller's ability to control lifecycle.

Such a feature is more of a user requirement. Where they don't care about
dependency ordering and are happy to get runtime exceptions (NullPointerException?)
when dependencies are not satisfied, instead of deploying beans and
the controller stopping them even getting exposed/run if there is problem.

A better approach is to use something like the GenericBeanFactory I just committed.
i.e. you inject a factory that can control object instantiation rules.

Generically, it is much better for users to do (a purer IOC?):

public void setFactory(MyFactory f)
{
 X x = f.create();
}

<bean class="MyClass">
<property name="factory"><depends name="MyFactory"/></property>
etc.
<bean class="GenericBeanFactory" name="MyFactory">
<factory and bean config goes here/>
etc.

than a locator style pattern, especially if the beans are
going straight into the registry instead of AppConfig being
constructed through dependency injection for each of its parts

public void setAppConfig(AppConfig appConfig)
{
 X x = (X) appConfig.getBean("SomeNameForX");
}