In point of fact, your first sentence is wrong. I know this because I tried for a better design via JS1.2 in Netscape 4, enabled by opt-in versioning (<script

In point of fact, your first sentence is wrong. I know this because I tried for a better design via JS1.2 in Netscape 4, enabled by opt-in versioning (<script type="application/x-javascript; version=1.2">). This was in 1997 while standardizing ECMA-262 Edition 1 (ES1). And based on this JS1.2 experience (in beta, and it went to final in Netscape 4 when that dog finally released), I argued to the Ecma TC39 TG1 standards group that ES1 should incompatibly change == and != to work as === and !== do in JS today and since ES1. Microsoft's JScript lead rejected this change as breaking, counterproposed the === and !== operators, and we all agreed. We also rightly decided not to impose opt-in versioning then, or ever after (1JS FTW). (Irony: in 1996 summer, the same MS lead had mailed me privately to propose some incompatible changes to give JS "a better design", but I couldn't make them without breaking the Web even then.) So almost 20 years later, asserting that something adopted widely and rapidly on the Web "could have had a better design without impacting [further] adoption" is easy to do but hard to prove. I did try, with == and !=, and that attempt bounced because of adoption-in-full (taking in versioning and backward compatibility). Number-locked versioning and related protocols such as content-negotiation via the Accept: header have failed hard on the Web, over and over. Sure, lots could have been better, but the time to get it right was 1995 May, not during standardization in late 1996 or 1997. At that point, "don't break the Web" prevailed, as it does still, among competing browser vendors. /be