So, between the ambiguity of Perl's "undef" and the clarity of SQL's NULL...You take an interesting position there. "Interesting" in that I've previously debated the merits of SQL's NULL with people who hold that it meaning is ambiguous in exactly the same ways that you say undef is ambiguous. (Does NULL mean that the value is unavailable? Unknown? Inapplicable? Something else?)
Personally, I think that both undef and NULL are fine as they are. Even if you split them into a flock of distinct not-a-values, at least one not-a-value will always be a catch-all for cases that fall outside the set of explicit not-a-values, so the ambiguity will always exist. Yes, the use of explicitly-defined not-a-values would reduce the need to use ambiguous not-a-values, but that comes at the cost of complexity in remembering how the various not-a-values interact and deciding which one to use in any given situation. Far better, IMO, to keep the syntax simple with a single not-a-value, relying on the programmer to indicate its meaning in any given situation and determine the appropriate behavior based on that meaning.