This is problematic in that you don't control external APIs. For example look at the DOM which preferences null but returns undefined when there is a language construct in the way:

    document.getElementById("asdf") // returns null;
    document.getElementsByTagName("asdf") // returns [];
    document.getEleemntsByTagName("asdf")[0] // returns undefined
    document.getElementsByTagName("body")[0].getAttribute("asdf") // returns null
    //
    document.getElementsByTagName("input") // assuming not empty for the next several lines
    document.getElementsByTagName("input")[0] // Element object
    document.getEleemntsByTagName("input")[0].value // returns "" as valus is implicitly an empty string if not supplied
    document.getElementsByTagName("div")[0].value // returns undefined even though the element is present but expresses an inference to an unsupported property

I completely agree supporting both null and undefined complicates some forms of validation, but I have accounted for this in my test automation. I don't encounter this problem with input validation or managing event handlers.

Here are the rules I use:

* undefined is a value where a value is never before assigned. Yes, you can do stupid things in opposition to the default such as arbitrarily assigning undefined or even redefining undefined to an assignment, but those footguns are not be accident.

* null is a value that is explicitly assigned.

If you program with those assumptions in mind you are safe 99% of the time given default language constructs, which doesn't account for the intentionally bad decisions other people make. This also helps with troubleshooting because when an error is encountered due to a null or undefined value the assignment distinction helps to diagnose the problem.