> how else do you grow a language for 40 years? You could introduce things in one version of the standard, and then remove them in the next release if people d

> how else do you grow a language for 40 years? You could introduce things in one version of the standard, and then remove them in the next release if people didn't like it, such that to get the feature you have to specifically use --std=2022a, no earlier, no later; and if you want your project to track the evolution of the language rather than getting stuck on a particular version, you'd have to rip use of such features back out. You could sort of think of it as if you had a dependencies lockfile which includes a version-constraint on the major version of the compiler; where every time there's a change in what code is accepted, that major version of the compiler goes up. Any change other than changing what code is accepted as valid goes into the lower semver fields; and gets replicated across all major versions of the compiler, where relevant. (Except that you don't have to do this by actually maintaining separate major-version branches of the compiler for every standards release; you can do it the way we currently do feature flags, only the only flag you get is which standard-version your project is written for.) I don't think I've ever seen anyone actually do this for a language/compiler; but it's a common approach used for protocol and API-client libraries, and seems to work well there.