> When Jan made that change, did GTK3 already exist?

Sure.

 > If not, then we
 > could avoid using that code for GTK3.

At the time he made the breaking change (June 2011) Jan remarked:

"This is so ugly, so maybe Emacs should remove Gtk3 support for this
release?"

Unfortunately he went on with the change and the chance to get rid of
GTK3 was lost forever.  BTW, I don't have the faintest idea how that
change works in the first place.

 > Alternatively, we could disallow making frames smaller than 4 lines,
 > because making our code jump through hoops for uses cases that are
 > supposed to be rare, to say the least, makes little sense to me.

That's what I'm trying to do because you asked for such a solution.  It
cannot be a fixed number of lines like 4 because minibuffer-only or
ediff control frames want less.  OTOH four lines are not enough when
shrinking a frame with say four windows stacked above each other.

Rather, I calculate, from the number of vertically stacked windows, the
presence of scroll bars, mode, header and tab bar lines and a plethora
of other factors a minimal height of the frame and try to pass that to
the window manager.  But GTK3 intercepts me.

To make this visually more evident: I ask for a minimum height of 11
lines and that information apparently makes it through to the window
manager which stops shrinking the window at 11 lines as requested.
Somehow though GTK manages to swallow the last three ConfigureNotify
events in the way I described in my OP, thus making Emacs think that the
frame stopped shrinking at 14 lines.  Consequently, our frame resizing
mechanism does not try to shrink the normal windows and the minibuffer
gets cut off from view as can be seen in what I attach as 11_bad.

The expected correct behavior (and the one produced after defining out
the XSetWMNormalHints and XSetWMSizeHints redefinitions) is attached as
11_good.

martin