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.
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.
Also, as soon as someone talks about "settings" there is usually a profound misunderstanding of how Emacs works at play.
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.