Hmm. Do people use PIMPL that much (I have used it, but rarely) that we need std library support (and testing, documentation, understanding)? Just asking.

It's often used in libraries where you need to guarantee ABI compatibility. Fixing a bug or implementing a feature may require adding a new member into the class, which would change its size (thus break ABI compatibility). PIMPL is the typical solution here, since the inner/impl class is not part of the public ABI.

I also like to use it sometimes to "hide" private methods and their documentation into PIMPL, so the public header is kept clean.

This std::indirect thingie looks more like a general helper for any data 'dangling off' an object, not limited to pimpl.

Not sure how much pimpl is used in reality, but it's a pretty ok solution to speed up build times (apart from unity builds), because it avoids having to include headers that are only needed for the private state into the public interface header.

It was used extensively at a former workplace of mine where each class that wasn't a message or data type was a pimpl. They had implemented their own private pointer class to handle it. It worked well enough to avoid pulling in lots of headers, but was still a PITA when you wanted to change methods as you'd always need to change the method signature in at least 3 places - header file declaration, source file definition, source file impl definition.

They didn't add PImpl support, they added std::indirect which can be used for PImpl among other things.

Yes, if you actually care compile times.

I remember using it all the time for the Windows headers because they pollutes the compilation unit like you wouldn't believe — the rule was to only include them in c/cpp files.

Back when I used to write C++ it was used all over the place. Admittedly that was a log time ago.