Company pointed me at this solution. See below for how I debugger the
issue:

GdkWindow keeps a pointer to the impl's cairo_surface which is the one
used to actually paint on. This pointer is retrieved by the painting
logic with _gdk_window_ref_cairo_surface() which gets it from the
backend if it's not cached yet else it re-uses the one it has.

When we clear the backend's cairo_surface on _update_size() we need to
clear GdkWindow's pointer as well. Otherwise we'd go on and commit a
new buffer to the compositor while the paint operation would be done
on the previous buffer and thus we'd get an empty buffer in the
compositor.

Depending on the compositor this issue could go unnoticed. For
instance, on weston's drm backend we get the release event for buffer
N very soon after buffer N's commit and since we destroy the cairo
surface at that point, the destruction handler installed by
_gdk_window_ref_cairo_surface() would run and clear GdkWindow's
cairo_surface pointer thus causing the correct new cairo_surface to be
fetched from the backend before paintint buffer N+1.

On weston's pixman backend, buffer N's release event arrives only
after buffer N+1 is commited. This means that for every odd new buffer
created while resizing, _gdk_window_ref_cairo_surface() would re-use
the cairo_surface for buffer N for painting and thus buffer N+1 was
commited blank to the compositor.