Armchair Language Design
How exactly does introducing classes or packages or optional typing “break existing code” or create "new interoperability problems"? If those features aren’t the contentious ones, which ones are?
Maybe Sam just has a way with words, or maybe Brendan said the same thing, but it's been lost in the hyperbole, but if this is the core issue, then why is it so hard for an outsider to figure this out? I'd guess because both sides are too busy calling the other a liar, which provides an excellent opportunity for people who know nothing about classes or packaging or optional typing to jump in and holler. Even the best parts of the LtU discussion revolve around lamenting the demise of a prototype-based language, along with some discussion of big-vs.-small languages.
Big vs. Small is actually one of the more compelling arguments here. I could write Javascript-ish stuff in .NET and get typing and all that if I wanted to. I've just never gotten that urge.
At the risk of being one of those people who knows nothing about type theory but feels compelled to comment anyway, I'd say the chief problem with interoperating with existing code is ECMAScript's current lack of a namespace system. This seems very much like the issues with XML's namespaces, in particular, the problems around default namespaces and working with non-namespaced XML. Jabber and RSS 2.0, anyone?
I'm trying to think of a strawman here. If what Gabriele writes is correct, all we'll need is Option Explicit and the Prolog cut operator and we'll have the most unholy union of programming language constructs ever devised. I expect that many of the people asking for strong typing will come to find that debugging a whole new class of runtime errors is probably even less fun than debugging errors that the compiler might have caught. I don't know all the facts, though. I'm pretty happy with ECMAScript 3 and this armchair's pretty comfy, here.