A traits class for (compound) pointers - beyond what std::pointer_traits offers
First, size_t should be std::size_t everywhere.

Why don't the raw pointer/array cases have release()? Granted, it won't really change any ownership in reality, but it could conceptually.

static ptr_type make(size_t count) { return new T[count]; }
static ptr_type make()             { return new T;        }


I'm not sure this interface is a good idea as is. This only supports Ts with default constructors. What about constructor arguments:

template &lt;typename... Args&gt;
static ptr_type make(Args&amp;&amp;... args)
{
    return new T{std::forward&lt;Args&gt;(args)...};
}


But of course, if you do that, it conflicts with the make(std::size_t) overload. So you'd need a different name for that, like make_n() or something, maybe with an interface like:

template &lt;typename... Args&gt;
static ptr_type make_n(std::size_t count, Args&amp;&amp;... args)
{
    return new T[count]{std::forward&lt;Args&gt;(args)...};
}


However, what about the difference between T{...} and T(...)? Now you need overloads for those cases, too.

Now, as for the overall idea, I'm not a committee member, but I can tell you with absolute certainty that this will never be accepted.

First, what actual problem in use is this supposed to solve? What is an actual use case where this is necessary and offers a significant improvement? I can't think of any situation where this will be useful. Certainly not one that's generalizable, which is mandatory for a standard library addition.

Generally speaking, memory management should be handled by containers, and containers use allocators, and this has no allocator support whatsoever.

Even worse, it hides the allocation method from client code... which is disastrous because you need to know how something was allocated to know how to DEallocate it. As it is, your interface offers a "handy" way to allocate memory, but no way to free it, and in fact goes out of its way to make code less safe by stripping ownership from smart pointers with the release() function.

In summary, I see no general gain from this, and plenty of dangerous drawbacks.