Most of the examples you point out make sense if you know that using greater than or less than casts the value to a number. >= and <= always cast their parameters to numbers while == only does if either side is already a number.

What a clusterfuck.

None of those are true when using `==` either.

The NaN example comes directly from IEEE754

The others are based on the fact that the two sides are not referring to the same object. C "equivalents" of your examples:

    int x[0], y[0]; x == y; // false
    typedef struct {} empty_t; empty_t *x, *y; x == y; // false
    int x[] = { 1 }, y[] = { 1 }; x == y; // false
    int x[] = { 0 }, y[] = { 0 }; x == y; // false

[] and {} create new objects. === always compares by identity, which isn't a unique feature. It's equivalent to Java's ==, and two different objects aren't ever equal to each other. === is equivalent to Python's `is`, and you'll get false from `[] is []` in Python for example.

Those non equations are perfectly reasonable.

One array or object does not equal another, different one.

There are definitely gains - I strongly suggest following the 'moral' of the story.

At least the === paradigm is fairly consistent and mostly rational.

This notion of equality would make pattern matching on empty lists or objects impossible in languages such as Erlang or Haskell. Perhaps it makes sense with the knowledge that each array is a different object, but it is highly counterintuitive.

Do any of those return true if you use double equals? The distinction only really comes up when you have to different types on either side and then It will coerce one of the types to match the other.

You're comparing two expressions of the same type so it doesn't matter whether you use == or ===, but == can return true even if the expressions are of different types.