> Very simply: it simulates the display.  See pos_visible_p (which
 > posn-at-point calls).  That's what I meant when I said that doing this
 > for determining the line width or height should be easy.

Here I see the following call sequences:

`fit-window-to-buffer'
   -> `count-screen-lines' -> `vertical-motion' -> move_it_to
   -> `pos-visible-in-window-p' -> pos_visible_p -> move_it_to

So everything `fit-window-to-buffer' does ends up calling move_it_to and
the loop called via `pos-visible-in-window-p' is likely silly.  Using

`posn-at-point' -> `pos-visible-in-window-p' -> pos_visible_p -> move_it_to

`window-end' -> move_it_vertically -> move_it_to

probably won't produce anything else.  This means that somehow
move_it_to fails to DTRT here.

I don't have a deterministic scenario to produce the bug.  I attach a
file you can try via `eval-buffer' followed by M-x foo.  After that
you'd have to resize the frame randomly (usually shrinking it
vertically) until it hides the last line(s) of the *foo* window.  This
usually takes a few seconds here.

The hiding does not occur when I do not draw a box around characters.  I
didn't try different character heights, bold face, etc. so far.  Note
that in normal work I use a maximized frame and the bug shows up
frequently when changing text in *foo* (using another hook) or the
window configuration.

I now have to manually trigger `window-line-height' on each of *foo*'s
lines when the hiding occurs, add the return values, and try to find out
what goes on.  This will take some time.  If you have a better idea, I'd
be all ears.

martin