That's a GNU extension, AIU supported by Clang as well.

I'm not saying we shouldn't do this (I'm glad of all libc headers we can do ourselves to avoid weird choices by the used libc), but it is in direct conflict with the first bulled of the coding convention. But if we start doing it, better change the code convention (or if that's what we do get a 2-ACK dispensation), and reap the fruit by using #pragma once, rather than creating a divide between what we do and what we claim to do.

+1 for updating the coding convention to match.

We actually already have an used of #include_next in the AVR code to automatically move format string to flash and use printf_P() to save lots of RAM.

I added a line to CODING_CONVENTIONS.md.
I think being implemented by both GCC and Clang is enough of a safeguard to prevent opening the gates to some crazy things.

We already use #include_next in esp32, tinyusb, posix and avr8_common - is the stdio case really any different?

I'd be more lenient in the cpu directories where there might easily just not be compilers other than the CPU specific one (AIU, neither ESP32 nor AVR can be built with off-the-shelf C compilers). Similarly in the POSIX case, its use is limited to native, which AIU also comes with a severe set of limitations by construction.

As for tinyusb and POSIX, I'd guess that neither reviewer nor author took care.

AVR can use upstream GCC (and we do so). Upstream clang is rather mature, but not feature complete.

ESP does indeed need magic binary only compilers.