> Those C89 hardliners have a different point of view.
C89 was only a thing because Microsoft somehow decided to drag it's feet and prevented msvc from supporting anything beyond c89 for a long, long time. Only in 2020 did they manage to finally do something about it.
Not in the embedded space. When you've worked on embedded systems long enough, you learn that you have to accept the compiler that the vendor provided you with, and you adapt your codebase to the limitations of that compiler. This means working around code generation bugs, adding #ifdefs to define typedefs for things like int16_t if they don't exist.
That said, things are a lot better than they were 15 years ago, and the mainstream ARM compilers used today are leagues better than the barely functional cobbled together ports from the early '00s. ARM64 is a tier 1 platform, and there are enough users of the platform that the extended QA team that embedded developers were unintentionally part of in the past is no longer really the case (at least when it comes to the compiler).
However, there are still truly obscure architectures (mostly 8 bit and 16 bit) that continue to have oddball compilers. And you accept and deal with that insanity because it means you're only paying $0.01 for that microcontroller to blink an LED when some kind of an event occurs.
_Generic is from C11 though. For array I wonder people don't use them more. After all, array access can easily be bounded-checked in contrast to pointers. I essentially eliminated all my spatial memory bugs this way.
C is basically going into "we want C++ but without OOP and with templates done via _Generic".
Also LLVM and GCC aren't going to be rewritten from C++ into Rust anytime soon.