It's even simpler. A lot of legacy code out there uses "0" (not NULL or even (void ∗)0, just 0) in place of NULL. So it's very important for backwards compatibility that "test ? (double ∗)x : 0" or "test ? 0 : (int ∗)x" return double ∗ or int ∗, respectively.
I'm not sure why the definition of a null pointer has to be so liberal, but I suspect there's a backwards compatibility constraint in there.
My mistake. I could have sworn that only C++ defined 0 to be equivalent to a null pointer. I guess my confusion stemmed from the fact that the NULL preprocessor macro in C++ is actually defined to be just "0" (or a magical-seeming "__null" in recent versions of g++), whereas in any modern C implementation I've seen, it's "((void *)0)".
Though there are cases in which passing an unadorned "0" as a null pointer can be wrong; there's a null-terminated varargs function example here:
I don't doubt the C99 committee did a fantastic job maintaining backward compatibility with extant code-bases which use ill- or un-defined semantics of older standards. But I don't think that the success of the committee at doing its job necessarily redeems C99 as a semantically sane language -- indeed, I would argue that the need for design-by-committee is indicative of the hefty baggage of backward-compatibility issues which necessitates such convoluted semantics and boxes the C language into a linguistic dead-end.
In the above case, I wonder if it's related to
and then wanting expressions like to have the type one would "expect" rather than whatever type NULL has in isolation.