There's a lot of nuisance because JavaScript has the same reserved words as Java. So for example you may sometimes accidentally find that this code barks an error at you:

   var x = new CustomObject();
   x.property.class = "some new class";

Why? Because 'class', even though it doesn't do anything in vanilla JavaScript, is a reserved word that cannot appear in this location. When you want to modify CSS classes, for example, you must use element.className to get that sort of access.

I mention this because in reverse, it is the same problem as your example. There are a bunch of default names in JavaScript which you'd expect to have but whose names aren't reserved words and can therefore be used just like variables.

One of these is 'undefined', another is 'Array'. These are both not so bad: if some fool misdefines 'undefined' globally you can just preface your own code with:

    undefined = void(0);

...to reset it. Here, 'void' is a Java keyword and so it will never be overwritten. Or if they redefine Array, you have the [] syntax to construct a new array and append elements to it; nobody really writes new Array() for anything anyways.

But suppose someone globally redefines 'isNaN' or 'isFinite' or both 'eval' and 'Function'. You're going to have a tremendously difficult time reimplementing those if you don't have them.

Nothing interesting, per current spec. a and b both get 1 assigned to them, in V8, JSC, and current Spidermonkey, and the value of undefined doesn't change. Carakan seems to still implement the old spec version, so it assigns 1 to all three. The presence or absence of var is not relevant.

The only reason a and b get 1 assigned to them is that the value of an assignment expression is always the RHS, no matter what actually happens to the assignment. Since "undefined" on the global is readonly, the assignment itself is just silently ignored.

All this without strict mode, of course; in strict mode the assignment to undefined throws.