I do not have as negative response as others(some of it is quite over the top imho), but I still think this kind of tricks should not be put in the standard.

Standard is for "everybody", and trick like this seems quite advanced/complicated to standardize/teach for the benefit it provides. 

Now you can say std::atomic or std::launder are quite advanced features, but the point is that you actually need them since problems they

solve are critical and there is no easier way to solve them.

 I think 3rd party library adding std::string_view/std::span overload is much easier than adding this to standard. 

That being said I do understand your point that you can not change 3rd party library code if they do not want to accept your pull request or code is not maintained.

So in that case I am all for you doing the trick in your own code(or even publishing it as a library), as in some cases it can help a lot with performance, and I do not see it realistically breaking ever(since C++ ABI is unlikely to change).

But as I said I believe it is too niche usecase to be added to std:::, especially considering I expect it would require quite a bit of work to make it not UB, despite that in practice as you said implementation is relatively trivial.

One future avenue that might make this possible is if we ever get constexpr strings whose storage can live across compile time/runtime border,  but I did not follow if there is any work wrt this. 

Idea here is that in this theoretical future we would get constexpr std::string to do your Pretender work in a way that it is a real std::string, but compiler + std::string implementation conspire to enable optimization so that at program shutdown destructor does not run, since memory it points to is not heap allocated.