>The RET for confirmation was a side-effect, one which the author felt could actually have some value in itself.
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.
That is how all changes work, especially for an editor like Emacs where the internal APIs are public. As far as I understand, the accepted workflow for Emacs dev is:
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.
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.