We think this is probably a bit too big of a change for its value, I agree that it better reflects reality (example below) but it's hard to gauge a potential breaks from something like this.

AbortController.prototype = () => {}
> () => {}

new AbortController()
> AbortController {signal: AbortSignal}

const a = new AbortController()
undefined

a
>  AbortController { 
  signal: AbortSignal {aborted: false, onabort: null} 
  __proto__: AbortController
}

We think this is probably a bit too big of a change for its value, I agree that it better reflects reality (example below) but it's hard to gauge a potential breaks from something like this.

I'm not sure I understand the reasoning here, your example looks like it will benefit from readonly? The reason it's silently ignoring reassignation of .prototype is because it's not in strict mode.

"use strict"; AbortController.prototype = () => {}
> Uncaught TypeError: "prototype" is read-only

(But I guess some polyfill can legally assign things to .prototype)

Can we move this PR forward?

We nowadays have better testing and hopefully the CI in microsoft/TypeScript side repo can catch potential breakage @orta was talking about on DefinitelyTyped. PR welcome (assuming one would also try the CI on TS repo too)

Before doing this, you probably need to consider microsoft/TypeScript#58296 as it may become necessary to remove the readonly modifier on some prototypes.

Not sure what those some would be. Would that be because of compatibility issue with packages?

No, it's because the PR would actually enforce that you can't assign an object with a readonly property to one that has the same property but mutable, and that relationship also applies to interfaces extending other interfaces. So, you can't inherit a mutable prototype and then mark it as readonly or vice versa.

But, maybe it would work out to mark all prototypes as readonly, it just doesn't seem like that's the way things are going based on the discussions about the PR.