Google is a company which uses C++ in a specific way. For example, they build most of their code from source with the same compiler and compilation settings, including external dependencies. They do not use exceptions, some parts of the standard library, some parts of the language. They also can upgrade their codebase in more-or-less atomic company-wide refactorings which also run most (if not all) tests for the affected code.

The C++ standards committee is a body of people from different backgrounds, different companies and different needs from C++. Moreover, they kind of have to cater to everybody. There may be people programming microcontrollers, there may be game developers, there may be people supporting/porting decades-old software which uses old versions of Qt, there may be people wanting all the modern bells and whistles in C++, and there may be people using pre-compiled third-party libraries from a long gone vendor or vendor not willing to upgrade their compiler.

These needs may contradict each other. ABI (Application Binary Interface) in C++ can be thought of as a `.pyc` file in Python. You don't expect _any_ compatibility of `.pyc` files between Python versions, so all libraries are distributed in source code in `.py`, and it's up to Python to process them into `.pyc` files as it wants. In C++ world, lots of libraries (including all OS libraries, actually) are distributed in a pre-compiled binary form only. The way your program interacts with the library is the ABI. If you upgrade your compiler, but the library does not, you can no longer use the library.

One example is the memory layout of standard library types. E.g. a release version of `std::vector` (the standard dynamic array container) may only need three fields: a pointer to the allocated memory, maximal capacity of the vector, and its current size. A debug version may also include stuff like "where this vector was created". If one part of your program (or an external library) expects a vector to be 24 bytes and have such and such fields, and another part expects something else, Everyone Dies(tm). To make things worse, everything breaks silently: there are little to no checks for ABI compatibility, and reading a byte almost always works.

As to why the standard is affected by this, even though "ABI" is not mentioned anywhere in the text: you cannot add/remove fields or virtual methods within the standard library in the next standard. If you do, the newer standard library _must_ become incompatible with all the pre-compiled code expecting the older version. (Almost) no way around it. A similar thing in Python would be if one has tried to use both Python 2 and Python in the same project simultaneously, in the same process.

So if everyone starts building all their code and dependencies from the source code, there will be no ABI concerns anymore. I don't see it happening any time.

> IIRC, the latest standard that all compilers implement fully is C++ 14.

Not even than, garbage collection from C++11 was never implemented by any compiler: https://en.cppreference.com/w/cpp/compiler_support/11

Not a big problem though, as it's never used by anyone. I've heard of people using non-standard garbage collection extensions instead, long before C++11. That's another thing with the standard and compilers: not everyone needs every feature, so some are given a priority depending on the compiler's users. And there are lots of existing solutions which probably won't be migrated to the standard.