Naturally, much of the C++ standard library isn't remotely suitable for AVRs, and should not be supported. However, there are a fair amount of features that I believe would work very nicely, and would be worthwhile to support. For example, std::array, std::optional, <concepts>, and the C++ counterparts to the C standard headers (e.g. <cstdint>).
For me, most of the <traits> is important to make programming easier. And all compile time constant containers as well. A long time ago, for gcc 4.x.x I was able to fake the gcc libc++ for avr and was able to use a lot of things from scratch. But I saw that it is a moving target to keep my adaptions working and stopped my work. I simply faked some of the ./bits/* files and was able to compile a lot of stl code. What I saw was a lot of dependencies to thread support and such. A lot of headers are including each other and it was more or less a big bunch of code not very well structured. But all this is decades away :-)
It seems that the usual solution for those seeking this functionality is to make their own implementation. While it works, I think it would be nice to have it provided by avr-gcc, if possible. I'd prefer to keep the boilerplate in the compiler rather than my projects. Is there a reason beyond a lack of interest that these features are not supported? I would be happy to work on this if so. Would selectively picking out parts of libstdc++ be a reasonable approach?
As said, it was possible with some hours of afford to fake parts of STL delivered with gcc to work on avr. But if there is no interest from others and stl will not be maintained for avr, it makes no sense to run behind the main platforms. And there is still the problem, that gcc has some very old design "bugs". One is vtable in ram and other code which directly goes to ram and makes it often impossible to use c++ for some "bigger" projects. I see me often writing hand crafted vtable replacements and "deoptimizing" switch/case and such stuff, because gcc wastes a lot of ram. Quite clear that it is fast, but ram is the most critical resource on avr. I moved to arm for a lot of projects, even if avr hardware would be nicer, but gcc was not able to generate the needed code for avr for given reasons. Missing parts of STL and the ram problem let me move to other controllers! Klaus