>>> These ones stupefied me when I tried to study your patch yesterday.
>>> When 'switch-to-buffer-obey-display-actions' is non-nil you do not
>>> reset 'force-same-window' so you can get an error when this is t and
>>> you're either in the minibuffer or the window is strongly dedicated.
>>> Right?
>>
>> I don't understand how 'force-same-window' can be non-nil if there is
>> a condition "unless switch-to-buffer-obey-display-actions" in the
>> interactive spec.  But if some code calls 'switch-to-buffer'
>> non-interactively with non-nil 'force-same-window', should it
>> signal an error when 'pop-to-buffer-same-window' displays the buffer
>> in another window?
>
> The non-interactive case is the one I had in mind.  I think we mean to
> say that FORCE-SAME-WINDOW has no impact in that case and

We already added this to the docstring two patches ago.
This was the part of that change:

 If optional argument FORCE-SAME-WINDOW is non-nil, the buffer
 must be displayed in the selected window when called
 non-interactively; if that is impossible, signal an error rather
-than calling `pop-to-buffer'.
+than calling `pop-to-buffer'.  It has no effect when the option
+`switch-to-buffer-obey-display-actions' is non-nil.

> 'switch-to-buffer' should not signal an error when the window is
> dedicated or the minibuffer window but try to automatically display
> the buffer in a window of its choice instead.

Do you think this is right?