jashkenas is one of the most prolific and talented JS devs around (CoffeeScript, backbone.js, underscore, docco are among his credits). I can see why he and oth

jashkenas is one of the most prolific and talented JS devs around (CoffeeScript, backbone.js, underscore, docco are among his credits). I can see why he and other library producers would want as much flexibility in the language as possible. Library consumers, on the other hand, will reap the most benefit from the proposed constraints. `private` is important metadata for a library consumer. Documentation generators can ignore private members, and private tags serve as roadsigns that the member can be ignored if one is only interested in the API. `private` is a very powerful filter. The same can be said for `const`: indicating a value shouldn't change eliminates one more thing one needs to hold in their head as they explore a lib's boundaries. I don't care at all about the performance benefits; I care about communication. `private` and `const` are nearly-free, expressive documentation. I actually like Ruby's "red tape" approach; it offers library consumers helpful metadata while still allowing flexibility. Maybe the best solution is for library developers to rigorously use the _private and CONST naming conventions, and reserve `private`, `const`, and `freeze` for security-sensitive code. Wouldn't that offer the most flexibility?