bug#48249: 28.0.50; Regression: emacs confused about window configuration due to ido-mode and/or winner-mode

[Gregory Heytings <gregory@heytings.org>]

>> When a low-level infrastructure has worked flawlessly for more than a 
>> decade, making significant changes in it without making them 
>> conditional to a run-time variable or a compilation option, until the 
>> new code is "proven" enough, is unwise.
>
> First, a knob to control new code is not always possible, though I agree 
> it is preferable when it's feasible.
>

It is _always_ possible.  Whether through conditional compilation or 
through conditional code.

>
> In this case, we do have a knob to control the new code, albeit not a 
> knob that goes back to the previous behavior with 100% accuracy.  It's 
> possible that the OP should try flipping that option, maybe it will work 
> around the problem (not that I think it's necessarily the solution).
>

Turning the knob doesn't work here, the bug occurs regardless of the value 
of that knob.  Otherwise I would have mentioned that in my reply to Dima.

>
> More generally, that's development for you; without risking such 
> destabilization from time to time we can never afford significant 
> improvements. The important question is: will the new-and-improved 
> behavior be useful or won't it?
>

Indeed perhaps the most important question here is: is this a "significant 
improvement"?  IMO, the answer is clearly "no".  Will this new behavior be 
"useful"?  In this case I'd say "perhaps, for very few users, even though 
nobody requested it".  But a marginal improvement that will benefit a few 
users is not worth taking the risk of unconditionally destabilizing old, 
time-proved code.

>
> Yes, of course.  The introduction of bidirectional editing support 
> during development of Emacs 24.1 comes to mind.
>

That was, of course, a significant improvement that was worth taking the 
risk of destabilization.