It doesn't matter what you call it. What matters is that you somehow distinguish between situations that are clearly true or false and situations that are not clearly one or the other. The exact mechanism by which you do this doesn't really matter (and what you call it really doesn't matter). What matters is that you don't discard the potentially valuable information that you just tried to do an operation that doesn't make sense. Making null>=0 return TRUE is like making 0/0 return 1.

Can you provide an example of when this would be useful? For example:

   if (foo.bar.length >= baz.buz) {
      ...
   } otherwise {
      // what am I supposed to do here?
   }

How do I disambiguate if the "broken" type coercion was actually what I wanted? How do I tell what circumstances conspired to make this statement not-clearly-true?

You'll have to provide some more details. Why would you want this broken type coercion? What are you actually trying to do here?

But in the absence of this information, my first guess would be:

   if (foo.bar.length >= baz.buz) {
      ...
   } otherwise {
      alert("Something unexpected happened.  Either foo.bar.length or baz.buz is not a number.")
   }

This sounds like throwing an error with extra steps.

Isn't what you're describing here basically equivalent to saying JS should throw on invalid comparisons, with

    try {if (x) then A else B} catch C

rewritten as

    if (x) then A else B otherwise C

?

Yes, except that the program would continue rather than halt if you left out the OTHERWISE clause. This seemed to me to be more in keeping with the philosophy of the rest of the language.

I'm trying to compare two completely arbitrary variables: the point is there's a dozen different ways where that comparison could involve type coercion. The "third boolean" value is useless unless you completely redesign the language.

> I'm trying to compare two completely arbitrary variables

But WHY are you trying to compare them? The fact that one of these variables is a field called LENGTH is highly suggestive of some particular semantics that you intend these variables to have.

> there's a dozen different ways where that comparison could involve type coercion

That's right, which is the reason I can't answer your question as you posed it.

I predict that if you try to fill in the details what you will find is that you will be unable to do so in any way that does not reveal the presence of something badly wrong in your design.

> The "third boolean" value is useless unless you completely redesign the language.

You have to add an OTHERWISE clause to the IF statement and change the semantics of some operators. That's not a "complete redesign."

It sounds like OTHERWISE is vaguely analogous to a catch on Java's ClassCastException (assuming it would be thrown for any nonsensical comparison). Traditonal if/else maps IF to true and ELSE to false|undefined; OTHERWISE simply extracts the undefined case to a separate clause.

Interesting way of expressing the result of an ill-defined operation. Or am I off base?

No, you're exactly right. If you think about it, both of these things are (almost) exactly equivalent. In both cases you are separating out a third control branch. The only difference is the syntax you use to specify what happens on that third branch, and whether or not that branch is taken immediately when the non-true-non-false value is generated. It is exactly the difference between (say)dividing by zero throwing an exception or returning an infinity or a NaN.

Exceptions are very much well-defined results. They just aren't the result you were originally expecting. But the meaning of a program is defined in terms of the language's own semantics, not what the programmer expects.