It would make a lot more sense to have a discussion before breaking long-used behavior. I'd use Emacs a lot more, but you honestly can't trust it. The developers don't see a problem with breaking things users rely on.
I think that the core problem is the article author saw a change that broke their workflow and didn't investigate any further for why it was made. They simply assumed they knew better and got annoyed that others saw some value in the original change. The very way it is presented in the article - as a change to add a confirmation for register overwrites - is a misunderstanding. The actual purpose of the change was to make C-g, the Emacs "cancel" key, work with register commands. The RET for confirmation was a side-effect, one which the author felt could actually have some value in itself.
I think for user facing features it makes more sense to provide new behaviors as opt-in, and go through a longer RFC period. Only if and when the new behavior is widely used and popular, then you flip the switch to default.
Regardless of the reasons for the change, a single author was permitted to commit a change that broke the workflows of potentially thousands of users. And there was no way users could work around it to maintain their previous workflows. That sounds arrogant and annoying.
1. Raise an issue through the mailing list.
2. Propose a patch on the mailing list
3. Maintainers send review comments about the patch.
4. The patch gets rejected or merged to master
5. The few people using head of master give feedback about the change
6. The change gets modified or reverted
7. A release branch is created from head of master
8. The bigger group of people who use un-released Emacs release branches start giving their feedback
9. More fixes are made on the release branch. Some features get reverted entirely.
10. A new Emacs release is decided and published
11. The larger emacs community starts using the brand new release and filing bugs and giving feedback
12. Release patches are sometimes issued, and other feedback is taken into consideration for the next release
13. After some minor releases, major Linux distributions start packaging the Emacs release to include in their official repos
14. Only now do the majority of Emacs users actually start using the new release, with all patches and feedback addressed.
In the case of this change, it has just made it at step 5 three days ago, and it is now in step 6. There is a LONG way to go before it makes it to any significant number of Emacs users. I actually doubt that there are thousands of users using head of master at all - out of which only a subset probably use registers in any way to begin with.
Personally, I've been using Emacs for 5+ years in my day to day job, and I am at a point where I build my own Emacs binaries. Even so, I'm only doing this from the latest release branch, and only close to a release, I don't have the energy to deal with the potentially broken head of a new release, even less so head of master.
Yes there was. Staying on version 29 of emacs. Or write everything that is needed in lisp to revert to old behavior.
For me, emacs developers breaks things for users the least and highly value backwards compatibility.