I greatly prefer Scheme-like lexical scoping. However, JavaScript does not implement lexical scoping properly. Given the particularities of JavaScript's inadequacies, I think that the CoffeeScript design is very reasonable. It's certainly not "broken".
JavaScript's lexical scoping is function-level. There is no block level lexical scoping, so variables are "hoisted" to the containing scope. This is why people use the (function(foo){...})(bar) trick to create lexical scopes, such as when looping (CoffeeScript's `do` keyword embodies this pattern). In my opinion, "proper" lexical scope implies shadowing without hoisting.
If you understand hoisting as a characteristic of JavaScript, its behavior is very predictable, and thus, hardly broken -- merely tricky if you've yet to encounter a hoisting-related issue.
That said, I find almost any issue with writing JavaScript can be easily mitigated by utilizing JSHint, and you get the added benefit of sticking with the base language, which is better because if you're writing raw JS everyday, your skills are more transferable than if you're writing CS every day if only for the fact that you can still write JS in a CS-only stack, but you can't write CS in a JS-only stack.
I'm not sure if you're telling me, or telling other folks in this thread, but for the record: I've fixed bugs in the ClojureScript compiler related to preserving the lexical scoping semantics :-) It's actually quite a tricky process and involves shadow tracking, symbol generation, self-calling function wrappers, and a bunch of other nonsense to deal with JavaScript's crummy semantics.
Of course, that link author suggests adopting a Python-like design instead, and Python is even more broken (Python has the most insanely awful scoping rules I've ever seen).
Really the problem is implicit declarations of any sort; they're great for one-liners, but they really suck when you're writing real software.
[But if you've gotta have 'em, please, at least don't copy Python...]
Nope. CoffeeScript's scoping is working the way it's supposed to be ;)
It's actually a funny thing -- out of all of the folks who actually have tried playing around with CoffeeScript in earnest (participated in issues or the mailing list), I can count on the fingers of one hand the number who have actually disliked working with the scoping semantics. There's a far larger number of folks who like to worry about the scope semantics without ever having tried it.
The whole point of lexical scoping is that code in an inner scope can't mess with an outer scope's variables without meaning to. CoffeeScript doesn't achieve that. The same code in an inner scope means different things depending on whether the outer scope uses the same variable names. It's broken.
Also, using really common identifier names (like "log") in outer scopes is a bad idea regardless of how your language's scoping works. Writing `{log} = Math` at the top of the file is just polluting your namespace for no good reason. You shouldn't do it, just like you shouldn't use `from math import *` in Python.
But a function in one part a file shouldn't be broken by the use of bad practices in a completely different part of the file. If I paste a function that works in the REPL into a file with other code, that function should always continue to work (unless it intentionally uses global variables, or another feature that is supposed to interact with other code).
Enforcing best practices by throwing errors where other languages wouldn't (like Go does) is one thing. Enforcing them by introducing difficult-to-track bugs into code that happens to be in the same file as other code which uses bad practices is another. This is a bug, not a feature.
It's not a bug, but it is an unfortunate quirk of the language. But find me a useful language without any unfortunate quirks, and I'll give you some sort of medal.
My point is that as unfortunate quirks go, this one isn't actually that big of a problem in practice, especially if you know to watch out for it and take simple steps to protect yourself from it.
There are Coffeescript forks that try to deal with issues like this. Here's one that takes a different approach on a bunch of 'em, including the scoping:
Lots more discussion here: https://news.ycombinator.com/item?id=3379962