When is ECMA/JS going to be versioned in <script> tags so we can avoid this the next time around?
Catering to an implementation that does bad things is an awful way to build standards, but it's only going to happen again and again and again unless the developer is forced to pick a version and build / maintain compatibility with exactly that version.
This is unlikely to happen. Browser developers don't want to maintain multiple forks of their JavaScript engines. They want new features introduced in a backward compatible manner so they can maintain a single engine. Imagine in 10 years if you had to maintain 7 slightly incompatible engines in parallel. A new browser written from scratch would have to implement all 7 engines since the older versions would never go away.
JS is no different from HTML in this regard. HTML has (at least) several variants of 4.x, quirks mode, HTML5, new features, deprecated features, etc. which all demand separate rendering engines. At some point, the browser stops supporting those things because they don't have to.
I don't know what kind of backward compatibility is inherent in their designs, but just remember <marquee> if you think that browsers have to support all features ad infinitum.
In practice, browsers does not recognize HTML versions. All HTML is handled by the same engine. This is one of the reasons HTML has moved to a living standard - the versioning was purely an artifact of the standard document and did not correspond to versioning in the rendering engines. (XHTML did introduce branching front-end parsers, which was a lot of wasted work.)
Adding new backward-compatible features does not require branching the engine, neither does removing older features.
The quirks/standards-mode distinction did require branching engines, and it has lead to increased complexity and testing burden. It was necessary at the time to move forward so the cost was accepted, but it is a complexity burden all browser have to carry for the foreseeable future. There should be a very good reason to introduce such branching - wanting to write "flatten" rather than "flat" is not a good enough reason.
Marquee was never supported by all browsers. But the article does mention some widely supported elements where support have been removed (<keygen>, <applet>) so it is not unheard of. But it requires that the element is almost never used on the web. Apparently this is not the case for MooTools library in question which still has some penetration.
Because I don't know what would happen if you don't define your version in script tags, it'll default to I guess LTS, which wouldn't have fixed this issue, right?
Right. It would have fixed this “flatten” issue, if the versioning change were done first, because those old sites wouldn’t have picked up the new “flatten” method. It would be opt-in.
>When is ECMA/JS going to be versioned in <script> tags so we can avoid this the next time around?
Unless there is a will to plow the ranks of committee sitters, and remove inadequate people, you will never see that till the moment the web platform kicks the bucket.
You seem to think that the committee sitters which believe in "don't break the web" are "inadequate". But this philosophy is shared by the browser vendors - they are simply not going to implement a standard which "breaks the web". You will have to convince browser vendors they are somehow better off if their software stops working as intended.
By far, it are those who oppose JS code versioning breaking the web.
The number of breaking changes since nineties is high hundredth already. Just each time they were opting to "break just few percents of websites, after careful considerations"
Catering to an implementation that does bad things is an awful way to build standards, but it's only going to happen again and again and again unless the developer is forced to pick a version and build / maintain compatibility with exactly that version.