Here is what I found:

The first time (doc-view-insert-image) is called, the doc-view buffer isn't
selected, and (doc-view-current-overlay) returns the t overlay.

The "fake" overlay gets "resurrected" when (doc-view-insert-image) calls
(move-overlay) on it.

Adding

(defun doc-view-initiate-display ()
  ;; Switch to image display if possible.
  (if (doc-view-mode-p doc-view-doc-type)
      (progn
+        (unless (eq (window-buffer) (current-buffer))
+          (set-window-buffer (selected-window) (current-buffer)))

prevents the t "window" from being set.

The second problem was that after splitting, new windows wouldn't have
overlays. What looked suspicious was that (image-mode-winprops) always ran
with the initial window. Changing the definition of
image-get-display-property from

(defun image-get-display-property ()
  (get-char-property (point-min) 'display
                     ;; There might be different images for different
displays.
                     (if (eq (window-buffer) (current-buffer))
                         (selected-window))))

to

(defun image-get-display-property ()
  (or (get-char-property (point-min) 'display (selected-window))
      (get-char-property (point-min) 'display)))

has fixed it. I'm not sure it's the right (only?) place to fix, since by
the time it gets called, (eq (window-buffer) (current-buffer)) should be
true.

Evgeni