I find this kind of thinking interesting. Like Emacs is a bold child that needs to shape up … rather than a conintiually evolving codebase developed by enthusiasts. If it doesn’t do “this thing” it’s probably because it doesn’t need to. There’s probably better ways to do this that experienced users are comfortable with. For the newbies then you only need workarounds to make them comfortable, such as that which I described.
I’m fairly positive 90% of any feature in emacs being unchanged in decades is directly attributable to backwards-compatibility than anything else. With how invasive emac scripts can be, it’s difficult to imagine anything to be changed without forcing the question: is it worth breaking userspace for this?
I don’t think the defaults are good — I suspect they’re stuck.
Why would Emacs turn down the possibility of adopting new user interaction concepts? It's not like we have to choose between "point" and "cursor", both concepts can coexist.
I find it funny to characterize Emacs as "evolving". There's been a lot of internal work, and some new features over the years, but almost all of the evolution happens on the Emacs ecosystem, not in Emacs itself. Core Emacs isn't evolving. Default Emacs is nothing more than a blank slate. And there's no clear, easy way to go from "blank slate" to "useful tool". It's either opting for one of the big config packages such as Spacemacs or Doom Emacs, or keeping Emacs as an Elisp playground (and I'd argue that an Elisp playground isn't a tool anymore, it becomes a goal in itself before it can be useful as a tool).
I find this kind of thinking interesting. Like Emacs is a bold child that needs to shape up … rather than a conintiually evolving codebase developed by enthusiasts. If it doesn’t do “this thing” it’s probably because it doesn’t need to. There’s probably better ways to do this that experienced users are comfortable with. For the newbies then you only need workarounds to make them comfortable, such as that which I described.