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