It'd be a different version that's not intended for backward compatibility. This would be beneficial for any new projects or new learners who don't need to sift through decades of changes.

There can still be the standard updates every 3 years for backwards compatibility, but Id assume version upgrades don't happen very frequently. Meaning, if a project is started on c++11 then it's probably going to stay on c++11 indefinitely, never making it to c++17 or some other later version.

If that's true then that would imply in general the projects using c++17 or later are created from scratch using that standard and therefore wouldn't suffer from backwards compatibility.

This is all said as someone who works with Java where I don't see folks migrating from Java 8 -> 11 or later.

In Rust this is done using Cargo (the build system) and each crate (library / binary) can choose a compiler edition that gates certain features which are not backward compatible.

You can use (depend on) a crate from your code that uses an old edition.

In C++, your idea would require enforcement at the compiler level but the linker should still link both "old" and "new" C/C++ together. Then the switch is done on a .cpp file (translation unit) level.

However the culture around C / C++ compiler development with standards and multiple compilers would require huge committees to decide what is "modern C++." There might be a lot of debate.

Much of the innovation in Python, C# and Rust is in how the process of language and standard library development is managed in the community. I wonder if C++ could do that?