> (This is for first frame without menu bar.)
 >
 > (window-pixel-height) ⇒ 1257

+ 35 pixels for the minibuffer gets us 1292 as expected.  Your main
window is 32 pixels too high, the lowest 3 pixels of the last line
(provided it contains text) should be cut off.

 > I can only suspect that this comes from a request to move the frame that
 >> doesn't show up in the history.  Now the only location where this might
 >> happen is in xterm.c around like 29259 here:
 >>
 >>          if (original_left != x || original_top != y)
 >>            XMoveWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
 >>                         original_left, original_top);
 >>
 >> Please put a breakpoint on that line and tell me whether it gets hit.
 >> The probability is less than 1% but who knows ...
 >>
 >
 > Nope, sorry, I put a breakpoint and it was not hit. Indeed, the whole block
 > starting at 29233 was not hit (I put a breakpoint at the call to
 > block_input on line 29245).

It was unlikely anyway.  Let us next check whether our event handler
drops events because they come with the same sizes.  With the attached
gtkutil-frame-2.diff and the first frame without minibuffer.

If you have any idea how to debug mutter on your system, we should be
able to get the cause right from there.  In window-x11.c the function
send_configure_notify calls

   meta_topic (META_DEBUG_GEOMETRY,
               "Sending synthetic configure notify to %s with x: %d y: %d w: %d h: %d",
               window->desc,
               event.xconfigure.x, event.xconfigure.y,
               event.xconfigure.width, event.xconfigure.height);

That height should tell us all.  IIUC you would have to set the
environment variable

MUTTER_DEBUG="geometry"

and then look into stderr (or redirect it) whether anything shows up.
IIUC mutter must have been built with a "verbose" option, so I doubt
that it will work for you out of the box but you could try nevertheless.

martin