>> The simplest solution is just to increase the number of seconds
>> in the user option 'image-auto-resize-on-window-resize'
>> proportionally to network latency.
>
> That's a global variable, right? So you would also delay resizing of
> images located locally.

Right, but disabling image-auto-resize-on-window-resize to nil in init file
will help as a temporary measure until this problem is properly fixed
for slow connections.

>> Locking could be implemented as well.  How would be better to do this?
>> Maybe by using a buffer-local variable?
>
> Yes. Something like
>
> (defvar image-fit-to-window-lock nil
>   "Lock for `image-fit-to-window' timer."
>
> (defun image-fit-to-window (window)
>   "..."
>   (unless image-fit-to-window-lock
>     (unwind-protect
> 	(progn
> 	  (setq-local image-fit-to-window-lock t)
> 	  ...)
>       (setq image-fit-to-window-lock nil))))
>
>
> There's also another thread. When image-fit-to-window is called from
> Emacs the first time, there could also be a running Tramp operation,
> which would be disturbed. See the recent discussion about "Tramp and
> timers" in the emacs-devel ML. Tramp would detect this situation, and
> fire the (new) error remote-file-error. This must also be handled, like
>
> (defun image-fit-to-window (window)
>   "..."
>   (ignore-error 'remote-file-error
>     ...))

Additionally to these changes, I also added canceling the previous timer
before starting a new timer to avoid several simultaneously started timers.
This improved responsiveness in non-remote case.  In remote case it helps
a little too, but still needs the lock for extremely slow connections.
Here is a complete patch (BTW, I'm not sure if the check for file-remote-p
can be removed now):