[dmurray]

I don't know much about this, but I thought this was a solved problem in the JS ecosystem.

You write Typescript or CoffeeScript or Clojurescript or ES6 or in this case "JS edition2023". You have a preprocessing step that compiles this into code that works on everyone's browser. Your new language has the features and quirks you want, without having to solve the problem of deploying a new runtime to a billion older machines.

[jraph]

A lot of people are still writing raw JS code, including me, because the tooling around this is way more lightweight and straightforward, or because of over things.

But yeah, as a preprocessing step, I'd argue a linter rule would be one of the best way to handle such a quirk if you are using bare JS (or TypeScript, which inherits this quirk, by the way)

[conaclos]

What I propose is introducing breaking changes via editions.

For instance, we could freeze class prototypes making impossible to dynamically replace a method or adding a method to it.

This what "use strict" did by forbidding `with` statements for example.

[bazoom42]

Browsers still have to support the older editions for backwards compatibility, so each new edition increase complexity.

[k__]

You never break user space.

[Thiez]

Only a Sith deals in absolutes. Presumably that is why proposed mechanism requires the user to explicitly opt-in, just like with `"use strict";`.