>>> If OT1H 'same-frame' is ignored when the selected frame is a
>>> minibuffer-only frame (so a new frame gets popped up instead) and OTOH
>>> the remaining action functions do use the last non-minibuffer frame in
>>> such case, then the behavior of 'display-buffer' is inconsistent in my
>>> regard.
>> Ah, yes, I see.
>> IIUC, the "inhibit-new-frame" semantics seems less susceptible to this
>> problem then the "same-frame", no?
> When I type M-x to invoke a custom function for displaying a buffer, I'd
> probably want 'inhibit-new-frame' to do what it advertises regardless of
> whether I'm in a stand-alone minibuffer frame or in a normal minibuffer
> window.

Indeed, but the difference between "same frame" and "inhibit new frame"
is that the meaning of "same frame" depends on the `selected-frame`
whereas "inhibit new frame" doesn't, so I think we're OK.

Here's a first candidate patch.

I introduced a new function `display-buffer--pop-up-frame` so as to
ignore `inhibit-new-frame` as a last resort.

I also modified `display-buffer--other-frame-action` to use
`display-buffer--pop-up-frame`, because it seems this is used only(?) in
response to an explicit user request where the user does expect a new
frame (like `C-x 5 b`) and so it seems to make sense to override even an
`inhibit-new-frame` coming from `display-buffer-alist`.


        Stefan


PS: Am I the only one who finds it confusing how some functions
named `display-buffer-<foo>` are meant to be used from the ACTIONs
(i.e. from within `display-buffer`) while others are implemented on top
of `display-buffer` (and thus should not be used within ACTIONS)?
Could we try and find a clear naming convention to distinguish the two,
or am I even more confused than I thought and several of those functions
can be used either way?