Yes, the -std flag would definitely still exist: the thing being changed by that flag is a lot of stuff in the parser, some stuff in the standard library, and some semantics bits further towards the backend, but at some point the versions converge and go through the same optimisation pipeline. A pipeline that definitely has seen improvements in more recent versions, so it's totally worth it to use a new compiler with an old language standard on old code: it might very well produce a faster executable. Just using an older compiler would also revert back to the old performance.

Additionally, a C/C++ compiler in an older standard mode would disable certain features, of course, but not completely: it's still able to give diagnistics in the vein of "this thing isn't valid with the current version setting, but it would be valid in C++17", for example. That's useful to a programmer.

A newer GCC will likely have better optimizations, better safety checks, or what have you that would benefit old codebases using older versions of C's syntax. Similar deal with a newer Clang/LLVM, for that matter.

That is, if we had a GCC version manager that worked the same way things like choosenim or rustup or pyenv or rvm or what have you work, I can guarantee you GCC will ship with an -std flag, because you can bet someone needs to compile a C89 codebase and wants the latest and greatest compiler smarts to do it. Same deal for Clang, or Visual Studio, or `zig cc`, or whatever.

Great example of this (that I just had to deal with this week, lol) is Wine, which mandates C89-compliant code, and yet absolutely benefits from any compiler optimization improvements introduced with newer versions of GCC.

Depends on your organization more than tooling. Even if you have the tool, your orgs security policy may not allow using it.

You may not have an environment that allows switching compiler versions for other reasons.

Even Rust has a similar concept that allows gating of features like this. They call it "editions".