I think you're being too hard on JavaScript there. Type coercion, ASI, and function scoping are all language features, not errors. Likewise, eval is not an error; it's dangerous, but it's also a feature (and one that nearly all dynamic/scripted languages provide). As Crockford said, "JavaScript is the only language people feel like they don't need to learn to use." That statement alone describes why so many developers end up scratching their heads at stuff like `1 == "1"`. That's not an error or an oversight in the language - it's a feature that the developer didn't realize he/she was using. It's hard to make it 10 minutes in ANY educational material on JavaScript that doesn't explain equality (==) vs identify (===) comparisons in JavaScript.
Lastly, the new class stuff doesn't actually change the inheritance/object models in JavaScript. It's syntactic sugar on top of prototypes, and the "weird constructor stuff" is quite analogous to existing constructor functions. For example, from the [ecmascript wiki](http://wiki.ecmascript.org/doku.php?id=strawman:maximally_mi...): "Class declarations/expressions create a constructor function/prototype pair exactly as for function declarations."
I'm clearly a bit of a fanboi and obviously biased, so take all of this with a grain of salt - but most of these new language features are a good thing. I'm glad to see JavaScript evolving in big ways. It was getting boring watching new editions come out with nothing more interesting than Array.prototype.reduce in them. Especially when you consider server-side contexts like Node.js, stuff like typed arrays, generators, Maps, etc. are welcome additions.
Eval sure, but the way that type coercion works in Javascript is an error. Boxing in Javascript is an error. You can figure them out, you can code around them, but they are bad and can't be justified. All coercion isn't bad, but some is.
Have you seen code that uses .valueOf() for anything good or useful? new String()?
Pre-JIT-compiling JS VM days, I did see new String used intentionally to eliminate auto-boxing overhead on every method called on a big string.
For ES4 (after AS3), we tried eliminating boxing. This is overtly incompatible, a web-breaking change. It won't fly.
Java has primitives that can be autoboxed or explicitly boxed too, which is why JS has them. I was future-proofing for "LiveConnect", which shipped in Netscape 3 (Nick Thompson did the integration).
But I was also in a terrible ten day hurry, so found unboxed primitives easier to deal with in the Mocha first implementation.
If I did not have the "make it look like Java" and ten-day marching orders, I like to think I would have resisted the lazy-programmer second reason. But it's all water way under the bridge now.
Implicit coercions, e.g., '' => 0, were influence by Perl 4. Nuff said!
Lastly, the new class stuff doesn't actually change the inheritance/object models in JavaScript. It's syntactic sugar on top of prototypes, and the "weird constructor stuff" is quite analogous to existing constructor functions. For example, from the [ecmascript wiki](http://wiki.ecmascript.org/doku.php?id=strawman:maximally_mi...): "Class declarations/expressions create a constructor function/prototype pair exactly as for function declarations."
I'm clearly a bit of a fanboi and obviously biased, so take all of this with a grain of salt - but most of these new language features are a good thing. I'm glad to see JavaScript evolving in big ways. It was getting boring watching new editions come out with nothing more interesting than Array.prototype.reduce in them. Especially when you consider server-side contexts like Node.js, stuff like typed arrays, generators, Maps, etc. are welcome additions.