Yeah, it's a bit tricky. Here is now I understand it:

What is fixincludes

In a steady state to build basic software you need a compiler (say, gcc) and libc (headers and libraries, say glibc).

In the best case gcc can parse and use glibc as is. In practice libc can come from the vendor and might be tailored to vendor's proprietary compiler. libc can use some fancy extensions that gcc does not understand for various reasons.

To work around that fact gcc generates so called "fixed includes" to be able to work on top of such mildly incompatible libcs. gcc uses fixincludes script with a bunch of heuristics. It's idea is to copy libc's header to gcc's own include path and slightly mangle it there.

How fixincludes breaks

On glibc there is very small amount of mangling happening. Usually glibc Just Works. But there are rare cases where it does not: when glibc is very old and gcc is very new. Or the other way around.

What is worse fixincludes is not very robust: it happily generates invalid headers (as in this case).

What is even worse is that nixpkgs swaps libc from under gcc during bootstrap:

1. gcc is built against glibc from bootstrap seed archive (usually ancient glibc). fixincludes are generated against ancient glibc.
2. glibc is built against gcc from [1.], then glibc is swapped in stdenv without gcc rebuild. This makes fixincludes` stale.
3. gcc is rebuilt against new glibc, fixincludes are generated against new glibc

[1.] and [2.] are the most fragile parts: they depend on glibc version both in bootstrapTools and in nipkgs. Those are different for different architectures in nixpkgs (it's a major pain).

Our breakage happens around [1.]: new gcc generates invalid fixincludes against ancient glibc. As a result we can't built a bunch of programs that try to use <statx.h> header.

The fix effectively throws away some of the invalid fixincludes and uses unmodified headers as is.

Reviewing now. If this works then it is a much better idea than regenerating the bootstrapFiles.