Thanks guys, I appreciate the responses.

Like I said before a lot of this is just experimentation as a learning experience on my part. So, this may very well end up with me saying "You're right, this is silly."

One example would be some 3rd party object that requires some state or ID as part of construction. If for your application, you can auto-generate the ID or cache the state used, you can create a construction policy to handle that for you. Another example would be to some way wrap CoCreateInstance for COM objects. This would allow you a standard/unified interface for creating objects.

So you'll probabily end up with pairs like HeapAllocationPolicy, HeapConstructionPolicy, and so on... defeating the purpose of policies of exploiting (nearly) all possible combinations of them.
I'm not sure I follow why that has to be the case. The placement new only requires a pointer to the object to construct, unless I'm missing some requirement of placement new. It doesn't matter if it's a pointer from the heap, pool, or shared memory segment (or technically, even the stack, though this is dangerous). In those situations, you could custom allocation policies with the standard construction policy.