> That wouldn't solve the problems with save-excursion.
You're calling save-excursion a "broken API", but it's in use everywhere - it is a staple of emacs lisp - and has been working for years. So yeah, offering an alternative for the 1% of cases where it isn't working as intended would solve the problem. With no breakage.
I don't get the impression that you're taking seriously the millions of lines of code that you don't have access to. That was written years ago. That was copied from the emacs wiki. That people are relying on, but no longer know how to change. It's not like you'll get a proper error message when it breaks.
> If/when the many other cases come storming, I might reconsider those tradeoffs, of course.
Are you seriously expecting users of Emacs to storm into emacs-devel in anticipation of their code breaking prior to a release? Or are you talking about rolling back a breaking change after the fact, creating issues for new code relying on new behavior?
It was just the other day that I pointed out a package in Emacs that's from 1999 to a friend. It's not been changed since. I used it as an example of how stable Emacs is, and how it allows for a piece of software to be done. Really done. This new attitude towards breaking changes saddens me in that light.
- Magnar