If performing it in full in those cases will take just a little more CPU
time, the result might be Emacs that looks more responsive under load,
and just as fast.
If you can find a way of reusing that information afterwards (more
than redisplay itself already does), yes. But AFAIU you are talking
about a thorough redesign of the Emacs display engine.
It already
attempts to reuse every piece of display that can be kept. For
example, if you type C-n on the bottom-most screen line, and you have
scroll-conservatively set, the display engine will redraw exactly one
screen line, and all the rest will be scrolled (via a direct Xlib
call) on the glass, without regenerating the glyphs.
It might be possible to construct some "cache key" that would allow us
to check whether the remainder of the command changed something that
would affect display. And if it didn't, use the last saved result of
move_it_*.
You will see in redisplay_window and its subroutines a lot of code
that attempts to do exactly that: figure out what has changed and what
hasn't. You are in effect saying that this must be radically
improved, in which case I'd happily agree, but please believe me that
it is not a trivial job, certainly not if you want to stay within the
current design of the display engine. You will probably need to
design and implement various new fields of the window and buffer
objects that will cache more data about the previous state of buffer
and display than what they already do, make sure these caches are
reset when no longer valid, then build new redisplay optimizations
based on those, find the conditions where the optimizations can and
cannot be used, etc.