Best way to do Nemesis-like scroll in screen 2

The best solution is to use a "circular" NAMTBL buffer.
When blitting to VRAM, instead of doing a single 768b LDIRVM, let's think in 24x 32b LDIRVM (one for each row).
If you keep an "scroll offset", ranging from 0 to 31, that 32b LDIRVM should: LDIRVM 32-offset bytes starting from the offset (in RAM) to the starting of the row (in VRAM), move to the beginning of the row (in RAM), then LDIRVM the remaining offset bytes.
Then you only need to draw the "new" 24b in RAM each frame.

For a single row: in RAM you have "ABCDEF" and offset 0, then you blit "ABCDEF" to VRAM.
The next frame, you have offset 1, so "BCDEFA" will be blit to VRAM. If you have previously replaced the A with a G... you'll have "BCDEFG" in VRAM

If you are a MAME user, check the VRAM (F4) in some games with scroll... most of them use the same principle (but hardware-based).

I did it this way in my (unfinished) World Rally clone, in case you want to check the code (https://github.com/theNestruo/msx-wrally/blob/master/src/ral...). This is slightly more complex (the scroll worked in two axis, so the offset ranges from 0 to 767) and the comments are in Spanish... but I hope the code is readable enough.

It is actually less complex that it sounds The tricky part is collision detection and to actually decode the new row/column from the data map. Ideally, the algorithm will be adjusted and optimized for your map structure (for example: if you use metatiles of 4x4 chars it may be convenient to make the NAMTBL buffer 36 bytes wide instead of 32)

I don't actually know how Konami did it...

My approach tries to avoid this ldir because it consumes... 23 * 766 + 18 = 17.636 t-states :-S

So NAMTBL is in RAM, and the same amount of data is moved from RAM to VRAM every frame in both cases? (I'm verifying because I intend to try doing something horizontally scrolling maybe next year.)

(When I was young, I tried to create in MSX-BASIC a snake game where the head was at array's first index and moving the snake meant moving all the body piece coordinates one step down in the array and assigning a new coordinate for the head (basically, the equivalent of that ldir operation). Obviously, I was dismayed when the snake slowed down before getting to any reasonable length...)

Yep, my code works this way. It is even easier (and faster) for vertical scrolling: in Freedom Fighter I had the whole level map in RAM about 8KB (decompressed from ROM before starting the level) starting from last map row till the first: to scroll within the map vertically I simply change the nametable start address of the 704 bytes buffer (first 2 rows are for scoreboard) decressing it by 32 bytes (a row) and copy to vram 704 bytes. On msx1 working in RAM is faster than copying from vram to ram, apply changes and copy back to vram