IoC, Where do you put the container?

The main benefit of Dependency Injection, at least in my applications, is the ability to write code that is context agnostic. From that perspective, your second solution seems like it really subverts the benefit DI could be giving you. If the 'god object' exposes different interfaces to each class that references it, it might not be too evil. But if you went that far I don't see why you don't take it all the way to the hoop.

Example: Your God object has a getFoo() method and a getBar() method. Object A needs a Foo, object B needs a Bar. If A just needs one Foo, Foo should be injected directly into A and A should not be aware of God at all. But if A needs to keep creating Foos, giving A a reference to God is pretty much inevitable. But you can protect yourself from the damage done by passing God around by narrowing the type of the reference to God. If you make God implement FooFactory and give A a reference to the FooFactory implemented by God, you can still write the code in A in a context-neutral way. That improves the opportunities for code reuse, and it increases your confidence that a change to God will not cause unexpected side-effects. For example, you can be certain when removing getBar() from God that class A won't break.

BUT ... if you're going to have all those interfaces anyway, you're probably better off writing purpose-built factory classes and wiring all your objects together, factories included, within the container, rather than wrapping the container at all. The container can still configure the factories.

Please, do not ever ever use static classes like IoC.Container.Resolve or ContainerFactory.GetContainer!

This makes the code more complicated, harder to test to maintain, to reuse and to read.

Normally any single component or a service has only one single point of injection - that's the constructor (with optional properties). And generally your components or service classes should not ever know about the existence of such thing as container.

If your components really need to have dynamic resolution inside (i.e. resolving exception handling policy or workflow, based on the name), then I recommend to consider lending IoC powers via the highly-specific providers

While I appreciate the explicitness of "purpose built factories" and even use them myself, this feels like a code smell in my own designs because the public interface (little "i") keeps changing with a new factory and/or a new GetX method for each implementation. After reading Jeremy Miller's It's time for IoC Container Detente, I suspect generics and injecting the container itself is the way to go.

I would wrap Ninject, StructureMap, or Windsor in some kind of IServiceLocator interface like the one proposed in Jeremy's article. Then have a container factory that simply returns an IServiceLocator anywhere in your code, even in loops as you originally suggested.

IServiceLocator container = ContainerFactory.GetContainer(); 
while( keepLooping )
{
    IExample example = container.GetInstance<IExample>();
    keepLooping = example.DoWork();
}

Your container factory can always return the same intance, you can swap IoC frameworks, whatever.

I'd recommend checking out Nick Blumhardt's mini-series on this.

http://blogs.msdn.com/nblumhardt/archive/2008/12/27/container-managed-application-design-prelude-where-does-the-container-belong.aspx