bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`

[Drew Adams <drew.adams@oracle.com>]

> I have no idea what you're talking about.  Please double check
> that you actually understand what the patch is doing (and take the
> `Subject:` of this bug report as a good hint for the intended use),
> and then clarify your argument.

I did look at the patch, and I understood that.
The only thing I objected to is having the value
of that user option be overridden by passing a
different value of the eponymous `display-buffer'
parameter.

> For example, `pop-up-frames` is not deprecated.

Yes, I know that.  I didn't say it is.  I only
mentioned, in parens, that I hope it remains
undeprecated.

To be clear, it's _good_ for `display-buffer' to
be able to do what `pop-up-frames' does.  Most
use cases would (I guess?) also be covered by
just binding the option.  I just don't think it's
great for such a work-horse function to override
an option value.

If the doc about the parameter made clear what's
involved (i.e., say that it overrides the option
etc.), and counseled against overriding an option
without letting users know that that's happening
(e.g. in the doc string of a command that uses
`display-buffer' this way), then that's probably
OK.

IOW, let's please refer to it as a user "option",
not just a "variable", and remind users of the
parameter that it's not very kosher to override
the behavior of an option without also letting
users know explicitly that that's happening.

If a user of a command knows that it overrides
an option then, well, using that command is a
choice.  And they can likely define their own
command that doesn't do so.  Can they do that
just by binding `pop-up-frames'?  (No, right?)