How would that help? The old functionality would still be around.

What would help is deprecating and, over time, removing features that, if needed, are better implemented on top of newer, better APIs. Providing source code for such an implementation would make it easy for old code to be changed to compile with the new version; all that would be needed would be changing #include <foo> by #include "foo" and changing references to the std namespace to that of the new library (there may be thorny edge cases here, but I can’t think of one)

For example, iostreams can be moved outside of the standard if an implementation of its API on top of std::format were provided.

I think they wouldn’t have to support such a library forever. A decade or two should IMO be enough. If code needs it after that, they can take on the burden of maintaining it.

C++ has become such an unwieldy monster that even though I've been primarily a C++ programmer from the very start of the language and am an expert in it, I've come to dread using it or maintaining software written in it.

Anything that stops or slows down the madness is welcome.

As long as old code continues to compile and run correctly on new compiler/language versions, I don't care what the committee does. From my point of view they should first and formost decelerate, so that there is at least enough time for compiler writers to keep up and collect enough experience between the standards. Cross-compiler compatibility has become an adventure since C++11. I only use a very conservative subset of the language to maintain compatibility.

I like the Rust way of telling the compiler driver with a command line switch which compiler version to run, then backward compatibility as a problem disappears.

If they decide to accept the Safe C++ proposal, it will require it. We’ll see.

I have no skin in the game and rarely code in C++. My answer is: no.