This allows us to simplify some code drastically and improve our QoI.
Seeing how much this simplifies D148432, I must say I kind of want to just do it.
However, this places an incredibly strict requirement on the library that all supported compilers are tested in the CI. Otherwise, we'll quickly start breaking the library with some compilers if they don't support those extensions. Similarly, this could make it more difficult to port the library to new compilers. We don't do that often and we could also require that new compiler ports only be for the most recent standards version (for example we'd support e.g. MSVC but only in C++23 mode).
All in all, I don't think the above is a dealbreaker. However, I would argue in favour of a slightly more gradual approach just to get a bit of experience with this before going completely crazy on it. For example, could we enable something like *just* the C++20 extensions for the conditional explicit feature within tuple (and nowhere else for now). And then after one release, we'd probably realize that it's no big deal, nobody noticed and it doesn't break anything, and we could do the whole thing. What I'm scared of doing is to turn on the whole thing, start doing refactorings and then realize that we have a big big problem that we can very hardly just git revert out of.
So yeah, I am in favour but I would thread carefully and start with changes in a focused area for one release, and see what we learn if anything. If we don't learn anything, then this is truly NFC and let's go crazy on it -- we don't lose anything and we gain a bunch.