In any case, if there is a way to dynamically detect these cases and
disable redisplay skipping for them, I'd like to try that out.
Yes, jit-lock-defer-time is that way. But you already know that.
No, it speeds up redisplay. It doesn't make *sure* that redisplay is not
skipped.
To do that, need to modify the condition of skipping redisplay.
Adding such a condition would be against Emacs design, which enters
redisplay only when Emacs is idle. As long as Emacs is not idle,
redisplay will be skipped, that's how Emacs is designed.
Even more if there was a way to put the results of "simulated redisplay"
to use in the "real" redisplay later.
That happens automatically, since the 'fontified' property they
produce is left on the buffer text.
That might be sufficient if we assume that font-lock is always the
slowest part of redisplay (for some commands it might not always be
true, but I'm guessing here).
Nothing else can be kept from the move_it_* phase, because the command
that is running might not yet have finished, and so not all of the
changes that affect display are known.
But with that assumption, the extra condition of not skipping redisplay
could be simplified (?) to only checking whether the current screen has
been fontified already (i.e. 'fontified' is non-nil). If it's fontified,
we won't skip redisplay.
I don't think forcing redisplay in the way that you suggest is a good
idea, see above.