prevent raising a frame from also input-focusing it

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

I normally use Emacs on MS Windows.  I sometimes use Emacs
on GNU/Linux, but the available version there is Emacs 21 (!).

I don't have any problem in either of those contexts,
preventing Emacs from coupling frame raising with
input-focusing the raised frame.  At least I haven't
noticed a problem.  (I cannot connect now to the GNU/Linux
machine, to check, but I think I would have noticed such a
glaring problem.)

On Windows I just set option `w32-grab-focus-on-raise' to nil.

On GNU/Linux (Emacs 21) I don't do anything special to prevent
automatic focusing of a raised frame, AFAIK.  Why I haven't
noticed a problem with GNU/Linux, Emacs 21, I don't know.

I received a report from a user of oneonone.el, a library
that (by default) creates a standalone minibuffer frame.
It reports that the behavior on GNU/Emacs is always like
that in Windows with non-nil `w32-grab-focus-on-raise':
*raising a frame always focuses it.*

Can users change this, please?  (Is this possible already?)

Here's a simple recipe, to show why this is unusable with
a standalone minibuffer frame:

emacs -Q -l "test.el" -f "test"

Where test.el has this:
(defun test ()
  ""
  (interactive)
  (setq default-frame-alist (list (cons 'minibuffer nil)))
  (setq pop-up-frames  t)
  (setq minibuffer-frame-alist
        (list (cons 'height 2) (cons 'minibuffer 'only)))
  (make-frame minibuffer-frame-alist)
  (setq minibuffer-auto-raise t))

In *scratch*, do `C-SPC'.  You see message `Mark activated'
in the echo area.  But the input focus is switched to the
minibuffer frame, away from the *scratch* frame!

(That is what I see on MS Windows, with nil
`w32-grab-focus-on-raise', and IIUC it is the reported
behavior for GNU/Linux.)

To print a message in *output* area (echo area), Emacs has
also switched the *input* focus to that frame.  This design
makes no sense to me.  It certainly makes trying to use a
standalone minibuffer frame problematic.

Please let me know how users can prevent this input focus
switch on non-Windows platforms.  Thx.

Why should raising a frame be coupled with input-focusing
it?  Why shouldn't users be able to control this?
(And why should such coupling be the default behavior?)