That’s not really a big deal in this context. Getting over the 2011 change was a big jump, and basically makes modern c++ usable for many more projects.
Lots of toolchains are pretty conservative also, 2017 is pretty new there. And much like the ISO standard, updates should be a lot easier now.
You will hardly find a C++ compiler that is 100% C++17 compliant, lesser so with those later standards.
Currently all C++ implementations are lagging behind ISO, as all major commercial contributors focus in other stacks, and take C++14 / C++17 as good enough for their in-house use of C++.
The bigger three have lost steam, while everyone else is even further behind .
Is there anything that GCC is missing? Looks complete to me [0]. Everything besides modules is also there for C++20 [1]. I'm at an automotive startup and we've been using a few C++26 features since summer already.
Are you ISO26262-compliant and your software is ASIL-A or higher? If no, why would you care about MISRA? If yes, how did you qualify a recent GCC?
Safety-critical automotive software development depends on tool qualification, which is often a lot of tedious work. There must be a spec, there must be tests, there must be proof that the tests cover the full spec, you must have a process to inform users about bugs. There is no free compiler which provides this.
Not yet compliant, but working on it. There's quite a few ASIL-D components too. We don't use GCC but rather tip-of-the-tree LLVM. Embedded is a completely separate and different mess using whatever the vendor ships for a particular microcontroller.
So far our safety guys haven't seen any issues with tool qualification besides requiring everything to be documented and the whole system to be re-tested in case of any tool changes.
This metric isn't really useful. This disregards any value of say a compiler implementing 99% of all features ever announced, including draft C++26 features, because it's missing a single C++17 feature preventing it from saying it's fully compliant so we shouldn't bother reading about anything but old stuff.
The big 3 already support features from C++23 worth learning about https://en.cppreference.com/w/cpp/compiler_support Obviously you can't always use that, but most places with a C++ compiler today support at least some useful features past C++17.
Your comment seems to have split in two, so I'll respond to this one as it's the longer of the two.
I agree it is annoying when compilers don't support the same features but my point is the question isn't whether there is an unimplemented feature from that revision in many compilers it's whether the feature you want to use is commonly supported. As an example, if you want widely implemented features like <=> from C++20 then it doesn't really matter most compiler stdlibs don't support riemann_zeta from C++17. Waiting for them to do so only sets you behind years or decades because you're looking for arbitrary features you'll likely never use to be universally supported too.
[1] https://www.ipa.go.jp/publish/qv6pgp00000011mh-att/000065271...