On Dec 5, 2023, at 10:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:

From: JD Smith <jdtsmith@gmail.com>
Date: Tue, 5 Dec 2023 18:06:41 -0500
Cc: 67604@debbugs.gnu.org

Before or after the test?

After the test.

OK, so this was likely a false positive then.  I’m out of ideas.  Maybe Windows is magically immune.

Unlikely.  More likely is that we need some specific metrics of the
displayed stuff to see the problem (which is therefore very rare).

For me both NS and Mac builds with your most recent xdisp.c fixes exhibit the same motion issue.  Do you have anyone you can call in to try the simple test on another build?

Not really, no.  But reproducing the problem is just a step towards
debugging it, so the alternative is for you to step through next-line
and its subroutines

I stepped through next-line and subroutines via edebug and landed via line-move-visual on:

(vertical-motion  (cons (or goal-column
    (if (consp temporary-goal-column)
(car temporary-goal-column)
      temporary-goal-column))
arg))

So vertical-motion is where all fingers point.

It isn't like I'm the only
one who should be able to read the code and understand where it fails.

I agree with that, but unfortunately am not setup for it here and have next to no familiarity with Emacs’ C code.  I’m sorry I can’t be of more help.  But similar to how you were unable to work with dvisvgm and other packages, I don’t have access to gdb, as it is not supported on my architecture.