The whole point of Emacs is that it is a radically customizable platform, and if you don't like the behavior of some feature you can modify it yourself with a few lines of Lisp. Forking the whole project over a change to one obscure feature makes zero sense.
Status: Emacs user since it was implemented as TECO macros (1981 or so), but I don't use registers.
One of the requirements for a radically customizable platform is that the platform itself must be extremely stable, otherwise everyone has to rewrite/fix every customization every time the platform changes.
What's the difference between "modify it yourself" and "fork"?
If this patch sticks, and someone wants it exactly the old way, they basically have to have a local repo of Emacs with the reverse patch applied, and then theirs.
Every time upstream Emacs changes, and they want to pick up the new changes, they have to rebase.
That's a private fork! Forever forked, forever rebasing.
Now you could play it fast and loose and try to monkey patch that; just load your file instead or after the shipped file to redefine the functions. That's still a kind of fork. You have to keep your materials somewhere as a project, and be prepared to adjust them if things change so that the monkey patching breaks in some way.
As far as I can tell this is simply not true. I don't think the change is a good idea but the hard fork also looks like a pure political play, not a technical one.
Also, as soon as someone talks about "settings" there is usually a profound misunderstanding of how Emacs works at play.
No, they didn't. It's Emacs. Every thing is dynamically scoped lisp. It's like if you could include arbitrary javascript in your vscode config and if you shadow any core function any code calling it will now use your function instead.
How is that not a fork? You have to maintain your function. Upstream can change in ways that your monkey patched function won't work; you have to maintain that going forward.
If you want to share your change with others, you have to ask them: which version of VSCode are you on, and give them the correct monkey patch which worked with that version.
You're doing everything fork-like except calling it a fork.
You know what? I was wrong, you're right. I thought this was a change to the core engine, but I looked again and see it's in the lisp. The user's ~/.emacs file can override this setting, so no hard fork is needed.
The whole point of Emacs is that it is a radically customizable platform, and if you don't like the behavior of some feature you can modify it yourself with a few lines of Lisp. Forking the whole project over a change to one obscure feature makes zero sense.
Status: Emacs user since it was implemented as TECO macros (1981 or so), but I don't use registers.