bug#46904: Non-unique windows produced by window-state-put

[Juri Linkov]

>>
>> Every time the selected window remains the same:
>>
>>    #<window 3 on *scratch*>
>>
>> But after splitting the window with e.g. 'C-x 2',
>> evaluating the same every time creates a new window
>> that it's expected to do even when there is only one window
>> on the frame.
>
> You mean we should do that
>
>             ;; Create a new window to replace the existing one.
>             (setq window (prog1 (split-window window)
>                            (delete-window window)))))
>
> in the one window case too?  This would be certainly more consistent but

This looks like the right fix.

> I do not remember any more why this is needed in the multiple windows
> case.

And I do not remember it too, maybe the current logic handled some use cases,
maybe not.

>> I don't know how severe are the consequences.  The only side-effect I noticed
>> that prev-buffers of restored windows are the same on different tabs because
>> they share the same window.
>
> If that is a problem and the above would help, let's do it.  It couldn't
> possibly harm unless the root window is too small to get split and we
> want to put only one window there; so we should handle that special case.

I'll try this, thanks.