But native scroll is native. There's no way for mosh, a program running inside the terminal, to know when a user is trying to scroll, and fetch data then.

If you want non-native scroll, just nest mosh inside screen/tmux.

(That may actually be why my theory doesn't work: once a line has scrolled off the screen, there's no way to update it, I think. So even if mosh wanted to do background, low-priority sync of scrollback, it couldn't. The only way to update the scrollback is to write the scrollback before writing the current screen.)

How many kilobytes are in 10000 lines of text? Less than about a megabyte, right...

There could be a happy medium mode or setting that enables scrolling as you described by emulating the keyboard behavior, but mosh would recognize through some buffer capacity if you catted more than about 1MB and skip to printing the last 0.75MB of it. (Makes me want to go on and read that patch you sent to see if I can get it to work like that...)

You probably didn't mean to read more than about 1000 lines of text into your terminal so you could mouse cursor select it by hand into your paste-buffer. You answered very informatively, thank you.

That's probably doable. I think you don't want to start with the patch I linked, since that disables all terminal sync and all use of the Terminal classes. Instead, try editing Terminal::Framebuffer to have a concept of both normal rows and scrollback rows, and adjust Terminal::Display's new_frame function to sync the scrollback rows in some different way. Note that there's already some code in that function to do scrollback, if the diff between two frames consists of scrolling.

(I haven't really contributed to mosh and haven't looked at the codebase in years, so asking on the mailing list or IRC is probably a better place to start)