Somebody has to write the code for your new feature. Either the code is inside the compiler written in either existing C++ (clang) or C (GCC) or it is written in a library. I bet with you that all the solutions are rather messy. It actually doesn't matter how messy the solution is inside the STL because the user does not have to write or read it. The perceived messiness from your point of view is not relevant for standardization as long as the compiler can easily understand it.

I have a counterpoint to make: More complicated code inside the compiler has the potential to introduce severe bugs–even for features that work perfectly fine now. I propose to write the simplest compiler possible so that we have the fewest bugs inside the compiler and programmers can rely on the compiler. If your new type is implemented in the compiler we will have new compiler bugs. If, however, in an STL implementation of your new type there is a bug, the bug will not spread to other code not using it. It is also easier to fix the bug (in the messy metaprogramming) because it is isolated to a single header file (and not spread throughout the entire compiler source code).

The worst part is that with "metaprogramming" you only mean "template metaprogramming". "Reflection" is the new type of "metaprogramming". And despite the name (or different definitions of the term 'reflection'), we cannot just inspect source code (using reflectors), but also generate new code (especially in future C++ versions). There is a lot of work being done to simplify metaprogramming and make it less messy. (Template metaprogramming is a form of functional programming. Reflection, on the other hand, looks a lot more like regular C++ code (imperative, OO programming). BTW, the term metaprogramming is traditionally not applied to just templated classes, but it requires computations to be done with templates.)