"undef" is not NULL and what to do about it

Sometimes undef is null, sometimes undef isn't. Adding "unknown" doesn't constrain these situations any better than using undef deos. In any given case you either know how to handle undef or you don't. If you know how to handle it, you handle it. Sometimes it very well could be the right thing to do is add 3000 (maybe that is what initial salaries are - though doubtful). Most of the time, you write your code to handle exception states.

The addition of unknown as a value type is fine (I guess). But it is only really an additional exception state. You could guess that unknown will behave more validly than undef, but I would wager that if you did that then most of the time you would just be guessing. Really, if your value is unknown, and you want your system to be well defined, then you have to handle unknown values and not blindly attempt to process them. This is no different than how you safe handle undef values.

In all reality the new "unknown" is really just another flavor of undef and carries all of the same problems and benefits that undef does.

Incidentally, the behavior you outlined for unknown appears to be very Perl6 junction-like and carries a little of the same benefit, but all of the same baggage that junctions do. Junctions in a very short scope are easy enough to follow, but at a distance there is grave magic.