"when the underlying JS changes (Like ES5->ES6) it can cause big breakage"
[Citation Needed]
As I understand it ES6 is meant to be backwards compatible with ES5.
CS classes won't make use of the new "class" syntax, but they should be compatible ES6 classes (they can subclass each other) because they're both really just sugar on top of JavaScript's prototypal inheritance.
Pretty sure the parent was talking about what I elaborated on -- see in particular
"... because when the underlying JS changes (Like ES5->ES6) it can cause big breakage and/or confusion (Will CS classes work like classes do in ES6?)"
Having two kinds of for-of loops and two kinds of classes, even if CS tries to present only its flavor and hide the underlying (but you can still escape out to raw JS from CS), does make for confusion.
Also, separate point, ES6 sucks oxygen from CS, so while I expect CS to live on, it won't see as much adoption as it would have absent ES6.
The reason to consider this is that if it's a big enough oxygen-sucking effect, CS might want to break its own backward compatibility in order to re-align with JS. I've heard talk of such a change, but I haven't talked about it Jeremy or Michael. Pointers welcome.
[Citation Needed]
As I understand it ES6 is meant to be backwards compatible with ES5.
CS classes won't make use of the new "class" syntax, but they should be compatible ES6 classes (they can subclass each other) because they're both really just sugar on top of JavaScript's prototypal inheritance.