certainly that's possible in some specific cases, but how would that behave in those situations where the allocator gets rebinded ? for example, an std::list<T> will not invoke the allocator for T ( it will allocate and construct some "node" structure composing somehow with T, how would you cope with such a situation ? ); in any case, you have no control on when or what is constructed but only on where it's constructed...
Rebinding is something I thought about a little later. I realized that the only way this would work is if the ConstructionPolicy didn't support a rebind, and the Factory would always just use the default. As things came along, ConstructionPolicy started having all kinds of rules with it that would work, but there were so many it was hard to keep track of (and code for).

After having played with actual code for this thing, running into some issues and the examples you've given, I give my design a thumbs down. Having little experience with designing libraries or complex applications, I'm still trying to balance complexity and extensibility with maintainability and practicality. Tough to do.

This is exactly the discussion I was hoping to have. Your examples (such as the std::clock_t one) are dead-on in showing where the two policy approach isn't helpful, and in fact more of a pain. In fact, while experimenting with this design I kept running the very thing you're describing. I just didn't realize that was the actual issue at its core.

Alternative issues I ran into were types that act like pointers (such as shared_ptr) and returning arrays of objects. However, I think this is a problem with std::allocators as well. For example, I can't think of how an allocator could be written such that it returned std::tr1::shared_ptr<T> simply because it's possible for allocators to return arrays of objects. Is this possible, or is it best that STL allocators work with standard pointer types only?