Screen 4 - vram usage

No. It is the table data format that defines the display of characters, patterns or bitmaps that changes depending the screen mode. R#2 always points to this table.

OK, a lot of assertions here are obviously true/right no one had doubt about this.

What is incorrect is that Yamaha engineers mangled the R#2 register to work only at fixed steps.If it worked like in TMS way one could have used to scroll at 1K steps the entire screen but the visible part of the next screen would have been visible when scrolling in this way (using R#2) instead of rolling up, which was the desired result. Otherwise a TMS way without R23 would have been unuseful, because you had the ability to scroll a page a 1K steps showing the contents of the next page, which was not desiderable.

So Yamaha engineers fixed the R#2 base address by "raping" its own meaning (the base address ptr) fixing the less significant bits and merging those bits with the content of bits in R#23 to get the address of the first byte of the visible screen area.
They patched the R#2 in the most quick and dirty way they needed to get the trick of having the ability of vertical scroll register.
They were required to do in this way because if they would have used all the R2 bits one could have used to move the beginning of screen data at 1K steps which combined with R23 values would have got to messy and unexpected effects.
(Imagine what you could get if R2 begin area would have moved down of 2K and R23 was set to 5). What should have been showed at bottom of screen ? ;-)

But it does not change at all the fact that R#2 is not an abstraction of page concept because YOU NEED TO WRITE different values in this register based on screen mode which is against the concept of abstraction (hiding details with a more logical approach to a page concept).

In others scenarios, like x-Y abstraction on logical commands they did the correct thing. For example if you want to turn a pixel at specified coordinate to a specific color (say color 1) YOU WRITE the same x,y, color values regardless of screen mode (and this is a true abstraction).

The R#2 mangling is instead a mess required to get vertical hw scroll which rolling from the beginning of screen that otherwise wirh only R2 was impossible.

the page concepts exists, obviously as proved by SETPAGE basic command. What you fail to understand is *THAT* page concept DOES NOT EXIST at hw level in vdp electronics at least for R#2 things, It is only a mangled usage of R#2 to get things working but the page concept is unknown to R2 only known to the programmer. Even in logical commands there is no real page concept at vdp level, because the vdp itself see its vram as a screen made up of X by 1024 pixels in G4/G5 modes and as X by 512 pixels in G6/G7 modes!
It's the MSX BASIC that when you do a SET PAGE 0,1 knows that a pset (0, 100) command go to be specified as 256+100 for y value.
the vdp only knows when it should begin to display the screen area given by a combination of mangled R#2 value with R23 value, so an address.

You can argue that Y=256 means Page 1 and this is correct: BUT IT IS A CONCEPT THAT YOU KNOW, not THE VDP ITSELF.
Different would be if the VDP had a "Working Page" register and command coordinates falls always in the 0-255 range. this is a page concept at VDP level.!

Glad you enjoy with basic vdp commands ;-)

If I would understand it on the level that you guys do, I would have made some cool games. Unfortunately, I am not so smart in these kind of things.