I actually had similar problems many years ago when I had
vector<unique_ptr<T>> and API was taking const vector<const T*>& , so this
trick worked fine :).

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.