Even without considering multi layering, a full-screen slab of magnified sprites is an interesting “screen mode” by itself. I wonder why nobody ever gave it a name… I propose SCREEN 3½. 
Given the lower resolution (128x106) and the pattern based nature, it is fairly cheap to update (1696 bytes), fits in a single frame by a fair margin. You can also keep up to 63 frames in VRAM. If you also update the colour attributes it costs more (2544 bytes), too much for turboR. VRAM fits 42 frames then. Full screen scrolling requires 224 writes.
Like the pattern modes it does have attribute clash and doesn’t have the friendliest memory layout. But on the other hand the 32x32 blocks can be moved flexibly and overlap in different orders.
---
I recall a pretty impressive racing game for the TI-83 (Z80-based, monochrome 96x64 screen), with the road curving smoothly up and down hills, in day and night, rain and snow… Can’t find a video, but that’s the power of having to transfer just 768 bytes per frame. Something like that seems within the realm of possibilities here too, without being stuck to screen 3’s low resolution.
The mode-2 sprites on MSX VDP is the worst 
rarely I've seen anything worse designed.
The natural way says us the color data to be placed on tables like the pattern data, aligned, so 255 patterns, 255 color data in another place of VRAM. NOT!, they used a fixed 512 bytes location to be updated dinamically depending on the 32 sprites planes. How awful! Spending much CPU updating the sprite color data.
Also, the "multi-color" is not really multi-color. At the end you need to use 2 sprites per each real one, so you have the same 4 flickering-free per line, and adds extra work to graphics designed because the OR is not easy to handle by someone used to only draw. Also no mirroring, a very useful and basic feature of hardware sprites.
Also, at the end, you notice that sprites can't be used to decorate, you need them for the game itself. Using sprites for border maskering or fill scroll planes, limits much what you can put later on your gameplay, as takes a good ammount of the 32 sprites, and adds sprites to lines for flickering purposes.
The MSX-Video and its peculiar design gives great functionality for computer, with impressive video modes, scanning (V9958) in an age that was very rare and expensive to have this feature in a computer. But for gaming performance it is clear that was not their main purpose, you have this, and do what you can with that.
For gaming the Amstrad design is better, based on blittering you have multi-color sprites, hardware scroll in any direction. But at the cost (the die size is limited) of limited video modes and features.
For what I have seen, we have:
- The Commodore 64 was a game console with keyboard.
- The Amstrad was a mixed machine, good for work and gaming, with 3 gfx modes for working and gaming. The problem was the software not used the hardware because most games were simple ports from Spectrum that lacks video hardware, everything done using the CPU.
- The MSX was the real computer, indeed the intention was to create a cheap open architecture alternative to IBM PC. Their priority was always adding features to the computer, not the gaming console part. So the sprites are more really for adding OSD and independent planes, i.e. the mouse cursor, not bothering the other elements.
The mode-2 sprites on MSX VDP is the worst rarely I've seen anything worse designed.
...
For what I have seen, we have:
- The Commodore 64 was a game console with keyboard.
- The Amstrad was a mixed machine, good for work and gaming, with 3 gfx modes for working and gaming. The problem was the software not used the hardware because most games were simple ports from Spectrum that lacks video hardware, everything done using the CPU.
- The MSX was the real computer, indeed the intention was to create a cheap open architecture alternative to IBM PC. Their priority was always adding features to the computer, not the gaming console part. So the sprites are more really for adding OSD and independent planes, i.e. the mouse cursor, not bothering the other elements.
frankly I do not understand what the C64 has to do with this thread, let alone call it Console with keyboard.
In fact, this MSX1 vs C64 thread leaves very interesting data from both machines.