Here is an updated patch to address Martin's comments.
More responses in line. Best!
Tom

> +                       (window (get-buffer-window buffer reusable-frames)))))
>
> Here the last line gets me

Argh. Yep, a copy/paste error out of a let form. Given your question
below I've rethought the issue, and now pass reusable-frames to
get-lru-window instead, which produces the expected lru behavior
when searching for a window over multiple frames.

> Now if this frame contains more than one window, 'get-lru-window' will
> usually (barring not fullwidth, dedicated ... windows) always succeed in
> finding a window.  This is probably not the intended behavior if this
> frame contains a reusable window - one that shows BUFFER already.  Maybe
> you think that some other action function would handle that.  But then
> why would you want to handle 'reusable-frames' here at all?

The reason I handle reusable-frames here is so that if a user wants to search
other frames for the least recently used window (e.g. they have 3
visible frames,
one for each monitor, and they want the lru window to be selected from any of
those visible frames). The implementation of this in that old patch
was completely
incorrect. In the new version reusable-frames is passed to get-lru-window, which
produces the expected results.

> Also 'display-buffer-pop-up-window' is an action function which returns
> a window _and_ displays the buffer in it.

Resolved so that we don't try to display the buffer twice.

> This
>
> +        (prog1
>
> has been cargo-culted from 'display-buffer-use-some-window'.  It's of no
> use here because you return the window used below.

Now gone.

> Finally, please fix the doc-string so it tells what this function really
> does (and please leave two spaces between sentences).

Done