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 .
[0] https://en.cppreference.com/w/cpp/compiler_support/17 [0] https://en.cppreference.com/w/cpp/compiler_support/20
Then there is the whole issue that many libraries authors cannot set in stone just one compiler / OS.
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.
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.
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.
Is it impossible to write a web page that works across browsers? Obviously not. You just need to check caniuse.com.
This kind of landmines is what keeps many code bases still using C++11 and C89.
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.