Undefined, implementation defined, and unspecified behaviour

Yes, they absolutely have talked to the POSIX guys about this - the issue is that there are three different conflicting POSIX-land interpretations of what realloc(ptr, 0) should do (AIX, BSD, glibc), and so we've ended up in this mess where POSIX doesn't want to pick sides, the C standard doesn't want to pick sides either (since as well as the three POSIX-land behaviours, it wants to support non-POSIX behaviours, too), and the result is a mess because no standards body is willing to stand up and say "this is the behaviour that you must have if compliant with this standard".

And no existing program is made invalid under C23; an implementation is allowed to define UB itself, and the older standards made it implementation defined with an absolute dogs' dinner of a set of permitted behaviours (notably, it was permissible to return a non-NULL pointer that you could not use). Because it was implementation defined, implementations have to document what they do with realloc(_, 0), and the C standard does not overrule your documented behaviour; rather, your documented behaviour overrules the C standard.

The dogs' dinner of choices for the behaviour of realloc(_, 0), in turn, was sufficiently bad that it was effectively UB under a different name, thanks to bad drafting in an effort to keep the conflicting behaviours of AIX, BSD and glibc all as permitted behaviours. As a result, if you're not going to choose a winner, it's more honest to define it as UB, and not as returning a pointer that you may or may not be allowed to dereference, with a requirement that you might be required to free the pointer that you passed to realloc if it returned NULL, but you also must not free the pointer that you passed to realloc if it returned NULL.

Underlying all of this is an unfortunate truth about the state of Standard C right now; ISO doesn't want to pick winners among existing implementations, unless it's clear that there is a "right" and a "wrong" answer. The Austin Group (POSIX) don't believe that they have sufficient weight with compiler authors to get compilers to comply with POSIX C in places where it defines things that ISO does not. And language users don't have enough weight with compiler authors to get an agreement together that can be taken to The Austin Group, or to ISO. Which leaves us in a situation where ISO is (correctly, per their charter) not defining parts of C that don't have a generally agreed upon meaning, but there is no way to get compiler authors to define things that ISO doesn't.

And that's bad for C users, since it leaves C users in a position where anything that's not defined the same way by every obscure C compiler out there cannot be relied upon between compiler version upgrades of a big-name compiler like Clang or GCC. Heck, from what I can gather, The Austin Group aren't even convinced that, if they were starting again now, they could insist that CHAR_BIT == 8 - the ISO standard says that CHAR_BIT >= 8.