...so what? It's just a header you have to #include.

By that logic why would anything have to be standardised?

The question is whether something belong in the language or in a library (possibly the standard library).

A guiding principle of C++ is that if something can be implemented cleanly and efficiently in a library, the language should not be extended to support the use case.

Now boost.pfr is exceedingly clever, but relying on speculative pack expansions or using stateful metaprogramming hacks is not something I would call clean and efficient, so proper reflection is warranted.

I do worry about the compile time impact though.

the only thing that should be standardized are things that cannot be done through libraries in an efficient way. Boost.PFR is great, I built a lot of things on it, but eventually you hit the limits of what a pure library approach can do -> language feature.

By your logic we shouldn't ever use external libraries.

PFR has given us reflection since C++14.

I also don't think the Standard Library is particularly well-defined nor well-implemented, as demonstrated by the atrocious compilation times.

The standard library shows the roots of the mid-1990s and there are a lot of things we would definitely do different today. However, it is still extremely well defined compared to most everything else. C++ is one of the few languages where the library actually guarantees how an algorithm works, which is both good and bad. The bad part is some things that made perfect sense in 1995 simply don't make sense in our modern CPUs where cache is important.