[swannodette]

and well-factored code has very few variables in the top-level scope -- and they're all things like namespaces and class names

Unless you happen to embrace JavaScript's functional side and write lots of top level helper functions (in a closure of course after which you export)

shadowing the variable is the wrong answer. It completely prevents you from making use of the original value for the remainder of the current scope.

This smells of static enforcement - strange for a language expounding JavaScript's dynamic nature and an odd departure from "it's just JavaScript".

Shadowing doesn't fit well in languages with closures-by-default

Not sure what evidence this is based on given the heap of great languages with closures-by-default that give programmers more control over scope without introducing goofy constructs like special assignment operators or global/nonlocal keywords.

CoffeeScript breaks the one real form of encapsulation (which includes the power of naming) that JavaScript has - function locals.

[jashkenas]

I may just ask you in a few minutes when you get in ... but what exactly is the scoping scheme (and generated JavaScript) that you're proposing here, without "var", "nonlocal", ":=", and with shadowing?

In addition, to repeat myself elsewhere in this thread, the goals here are conceptual simplification and readability, not giving the programmer more control over scope. The final result is that hopefully:

    someVariable
      ... more code here ...
        someVariable
          ... more code here ...
            someVariable
          ... more code here ...
        someVariable

... in the above code, you can know that "someVariable" always refers to the same thing. With "var", the above code could allow "someVariable" to refer to three different things, each for slightly different sections of the above chunk of code.

If you really want three different values, use three different names. In all cases, it will read better than shadowing would have.

[pwpwp]

In all cases, it will read better than shadowing would have.

You are going against the consensus established by ALGOL and Scheme (and used by most languages in the functional camp since then) here. That's your prerogative of course, but personally I'd be wary of design choices that go against established wisdom.

With "var", the above code could allow "someVariable" to refer to three different things, each for slightly different sections of the above chunk of code.

Yes, but that's not an issue, as it is easy to check (by looking at the code section in isolation) which of the three bindings an identifier refers to - which is, for me, the definition of lexical, static scope.