This could also be just an overload to Register that doesn't receive parameters...

Yeah, I think a parameterless Register() overload would be a nice way to do this.

Actually this is close to what I was looking for, you should also consider a Register overload that doesn't take typed parameters, i.e. container.Register(typeof(Interface), typeof(Impl)) so we can auto register a type at runtime (on AppDomain startup).

Oh man, I just gave this a go in a test project and it cleaned up the registration code a lot. Particularly if you add this method:

    public static void Register(this Container container)
    {
        container.Register();
    }

... so that you don't need to specify both the interface and implementation of the service type (if they're the same).

I've posted about this in the discussions but it may get lost so I'll re-post:

I've developed a generics/expression based AutoWire wrapper for my web service framework that lets you register 'runtime types' around Funq's generic interfaces here:
http://code.google.com/p/servicestack/source/browse/trunk/Common/ServiceStack.Common/ServiceStack.ServiceHost/ExpressionTypeFunqContainer.cs

It's built with the same spirit as Funq where all the perf cost happens during the 'registration phase'. Basically when you register a 'runtime type' it goes through and 'binds' the Funq resolver to the largest constructor and all its public properties that have registered dependencies.

It exposes the following API's allowing you to register 'runtime types':

public void RegisterTypes(params Type[] serviceTypes)
void RegisterTypes(IEnumerable serviceTypes)

At the moment it's just a wrapper class around the Funq container so I could add this functionality without modifying the existing Funq code-base.
Although if this is a useful (and right) approach I could rewrite it as an extension method or merge it into the existing code base, etc, whatever is the preferred method.
Of course it will only work in environments that support expressions.
I do have developed an equivalent Reflection-based solution for this purpose, although it is probably not best to include these slower API's as the whole point of Funq is to run fast on embedded devices :)