Consider the following:

1. emacs -Q --daemon

2. emacsclient --create-frame

3. (selected-window)
     => #<window 3 on *scratch*>

4. (other-window-for-scrolling)
     => #<window 1 on *scratch*>

5. (frame-terminal (window-frame (other-window-for-scrolling)))
     => #<terminal 0 on initial_terminal>

This can result in commands scroll-other-window and
scroll-other-window-down scrolling the "phantom" initial frame of the
daemon instead of signalling a "no other window" error.  I imagine this
behaviour is never desirable.

I believe this issue and its potential resolution share some ground with
bug#27210 in that the daemon frame is counterintuitively considered
visible in the following repeat-until condition in
Fother_window_for_scrolling:

  do
    window = Fnext_window (window, Qnil, Qt);
  while (! FRAME_VISIBLE_P (XFRAME (WINDOW_FRAME (XWINDOW (window))))
         && ! EQ (window, selected_window));

Until a more thorough review of the visibility of the initial daemon
frame is reached, I propose the attached patch to additionally ignore
the daemon frame in the aforementioned repeat-until condition.  I assume
the overhead of the additional loop logic and IS_DAEMON invariant is
negligible compared to the rest of the function.

An alternative approach to the attached patch would be to limit "other
window scrolling" to frames in the current terminal, as per the spirit
of bug#5616: