[roguesherlock]

I actually find all of the return values reasonable.

As you said,

undefined == I just don’t know what the value is

null == I know that there isn’t supposed to be a value here.

[amw-zero]

Why is this distinction important practically?

[lmm]

Because they mean very different things. E.g. "no-one owns this land" is very different from "I don't know who owns this land". "You don't need to do anything" is very different from "I don't know what you need to do". "No-one's in that room" is very different from "I don't know who's in that room". Of course the practical difference depends on context, but so does the practical difference between 2 and 3.

[amw-zero]

That’s not what I asked. I know what the distinction is. I asked why would I ever need that distinction in a program.

In 10 years I’ve never come across a situation where I found that distinction useful.

[thenanyu]

Agree. I would never attempt to write flow control that had different cases for handling undefined and null. It feels so extremely brittle

[reificator]

Undefined should mean in most cases that you've made a programming mistake, be that a typo or an invalid assumption about the type of thing you're getting back.

Null should mean in most cases that the data you wanted to access was invalid, but you can expect it to exist there in other circumstances.

Neither are a guarantee in JS, and you can find counterexamples for the counterexamples of the counterexamples, but that's the intention behind each.

[megous]

In the past it was one of the ways to distinguish between arguments to function that were not passed in by the caller.

[jolux]

It shouldn’t be but due to the way JavaScript is structured it is.