Compilers should at least support -Wall2017 or something then, enabling warnings in existence in that year and failing compilation for years in the future.
Yes, this is exactly right. If you want to automatically upgrade a thing, you need a way for them to pin their existing config so it doesn't break. A good analogy here is Stripe's API versioning: they keep making it better, but you're pinned to the version you start with until you upgrade (which you can do selectively).
In OCaml there is a very simple rule: Development builds run with "-warn-error", which is OCaml-speak for "-Werror". Production builds run without that option - simply because future version of ocamlc might introduce new warnings that would make the build fail.
This makes a lot of sense to me.
Why did the C/C++ ecosystem adopt a different aprroach to production build compiler options?
There isn't really a single coherent "C/C++ ecosystem", but for your average "build with make" program there isn't really a 'production' vs 'development' build distinction that would be easy to hang this off. (QEMU enables -Werror for builds from a git tree but we had to put a bit of special purpose in our configure script to do that.) You can't tie it to "is this a debug build" because some warnings only appear for optimised builds so ideally you want to have the check for both debug and optimised.
You could add -Werror to cflags in the makefile on the condition that some release build specific environment variable is set, though just adding separate release/debug/dev targets doesn't seem too tricky.
People who do production builds with -Wall and -Werror ruin it for the rest of us.