Since the "Array" is a reference to the prototype, I think it might be outdated due to changes in undefined behavior of runtimes when serializing array objects, or logging them.

I'm pretty sure that [object Array] used to be the result of logging an array at some point.

  Object.prototype.toString

  Array.prototype.join

My explanation was that it signals intent to me, and is different from some property not being part of the expected object shape or not having been initialized because of some accident or logic failure.

Since then, I've sticked to it, and am "allowed" to use NULL ^^

It can lead to some annoying checks in TS for primitively-typed properties, so for these, I still allow explicit usage of undefined when it's simpler given the surrounding code.

But I agree with you in principle. Using "undefined" as a "second nullish value" and explicitly checking for it is a programming error.

When there's object/areay vs null/undefined, thankfully, the truthiness narrowing often allows me to interface with code relying on "undefined" without explicitly handling this "value" in my own parts of the code base :)

undefined camp:

- out of bounds array index access [1,2,3][42]

- non existent object key access {}.foo

- array.find(...) no result

- ...

null camp:

- document.querySelector(...) no result

- regex.match(...) no result

- ...

No: it's the type that has one inhabitant—it's not that type's fault that it appears as a default argument or var or was left out of JSON... So long as typeof null === "object", null is the absurd one