NInject and StructureMap both have contextual dependency injection, and Hiro is going to be mostly conventions based.
It'd be nice if MicroKernel and Windsor supported more conventions-based approach, possibly something similar to what I outlined here: http://kozmic.pl/archive/2009/04/09/convention-based-dependency-injection-with-castle-microkernelwindsor.aspx

some people find current fluent API too verbose and hard to discover:
- connect that for method that takes params IRegistration[] you have to use either Component. or AllTypes.

Perhaps a default implementation of IWindsorInstaller that exposes protected methods working with nested closures to be more discoverable, would be a good addition

InjectMembers(instance) - resolve dependencies on an existing instance without registering the type in the container. That would be useful for situations where the instance is created by someone else (like the Page instance in ASP.Net WebForms).

- Global settings - make it nicer to:
- Default Lifestyle setting
- Default disposable tracking setting

Do not use special extension points for anything other than Facilities
and Subsystems.
For things like IModelInterceptorSelectors, etc just have them
registered into the container
and resolve them as needed, much like ILazyComponentLoaders are handled.

Here is a sample: http://geekswithblogs.net/wesm/archive/2010/02/25/sexy-windsor-registrations.aspx

Basically like StructureMap's registry class and FluentNHibernate's mapping classes.

It would be interesting if Windsor could support the interception of calls made to services created via the 'UsingFactoryMethod' syntax:

container.Register(Component.For<ISomeService>().UsingFactoryMethod(()
=> new
SomeServiceImpl(5)).Interceptors(InterceptorReference.ForType<SomeServiceIn terceptor>()).First);

Currently, this will generate the following exception when any member of the resolved service is called:

System.NotImplementedException: This is a DynamicProxy2 error: the
interceptor attempted to 'Proceed' for method 'Int32
DoSomething(Int32)' which has no target. When calling method without
target there is no implementation to 'proceed' to and it is the
responsibility of the interceptor to mimic the implementation (set
return value, out arguments etc)

All other lifetimes can be derived from these two with child containers.

Also, supporting only these two fix the invalid situations where lifestyles are incompatible

UsingFactoryMethod method from Fluent API should be made into overload of For<> so that

Component
.For<IFoo>()
.UsingFactoryMethod(kernel => kernel.Resolve<IFooFactory>().CreateFoo())

becomes

Component
.For<IFoo>(kernel => kernel.Resolve<IFooFactory>().CreateFoo())

This feels more natural, is consistent with other frameworks, and limits the number of methods on the fluent API which improves discoverability

Allow passing an interface and a Dynamic Object, then generate a proxy which delegates to the dynamic.

Would be very useful for interoperating with DLR languages / Duck typing.

Currently the API does not guide users towards "correct" usage. It might be beneficial to re-design it so that it's much more explicit as to what should happen when.
It could do what some other containers do - explicitly split into two phases - registration and usage (like ContainerBuilder -> Container).

Make http://using.castleproject.org/display/IoC/Strongly+Typed+property+wiring+with+Fluent+Registration+API part of the core Windsor code.
The startable facility registration already has some Expression<Func<?>> stuff, so why not apply this to any registration.

- Generate proxies to match up lifestyles of components that have different life styles.
- So if I am singleton and depends on request scope stuff, I get a proxy that match that up.

Create an interface, implemented by the container, that only allows registration. This way, I could restrict the use of the service locator pattern without restricting the ability to actually register components.

smaller assembly means smaller memory requirements. think of WP7 scenarios

Given a generic interface IM<> and two implementations M1<T> where T : ISomeInterface and M2<T>. When we have a class A1 : ISomeInterface and we resolve IM<A1> it should return M1<>, rather than M2<>. When we have a class A2 that does not implement ISomeInterface Resolve<IM<A2>> should return M2<>. Here's a worked example: http://gist.github.com/622123

Ability to register components in XML is mostly a leftover from early days of Windsor before Fluent Registration API was created. It is much less powerful than registration in code and many tasks can be only accomplished from code.
So why keep on supporting an old and outdated registration mechanism.