why a so stupid mistake?

umh, to be sound very strange. If v9938 was the msx vdp, why it has support for msx1 modes that are almost useless?
ok, maybe they were forced to add support because of the early adoption of tms when the v9938 was not ready for msx1 but... to me it sound strange. I cannot find evidence on v9938 to prove that.
I judge more likely they later saw the limit of tms and created the v9938 to patch the problem.

However, what tms in mainly lacking is 8 or more sprites/scanline and horizontal/scroll register. The latter are not so much hard to add. the first probably require some tricks in bandwidth memory management.
With those functions i think the tms vdp could do better than the c64 VIC-II

You have to put yourself in perspective of what they wanted to achieve.
It was NOT about performance, but rather about benefits and rapid market invasion.

So they made their market and choose simple and cheap components, available in large quantities. Some of them were efficient, but some not. Some of them were indeed already obsolete at the time, like the TMS VDP.

MSX was not a "designed" computer, in the sense that they did not develop new components for it. It was an "assembled" computer, made from readily available parts. Also, the Z80/TMS/PSG combination was already a solution used in other computers : Colecovision, Yeno SC-3000, ...

- for me this is the usual overestimated bottleneck direct vram access.
1) i can say that there are also bad - lines that are from the fact that the vic 'caches' on row of so-called-in-msx-nametable and keep it valid for 8 scanlines. but when he need another charater row it need time to fetch 40 bytes (screen width) from ram and stall cpu for 40us. If you combine the sprite hw visualization there are other 3bytes x sprite on scanline = 24us of stall.
and entire raster line of lock for the cpu in the worst case.

both systems use charater based gfx and the less nametable write you have to do on msx (768bytes) compensates for the c64 ones (1000 bytes)+so-called-color RAM.

2) the vdp protocol is not so a big limit in contiguos areas of vram read write operations that are the common cases.
of course if you need to turn on pixels in random positions of the screen you do get a lot of bottleneck on msx than on c64 due to the need of set vram ptr.
Otherwise when you write the entire SAT for example, maybe you go faster on msx than on c64 with a direct memory mapped vram address. Just remember that on c64 there are no block move operations so you need to implement LDIR via sw that is most probably slower (remember that you also need to maintain a byte counter to keep track of the number of bytes transferred + conditional jump and loop) than a otir or a bunch of outi in vblank.

IMHO the real vdp limit are :
1) 4 sprites / scanline limit. BARELY enough if you have one main charater + one enemy + one bullet for each schema. otherwise, let's flicker party start.
And i will point out that the VIC-II chip is not a memory hungry bandwidth monster as it does appear. It's only better engineered. Look at the sprites. They have multicolor, but at no cost of VRAM bandwidth. Teoretically having 4 sprites color should double the vram bandwidth requirements, but engineers clever managed to get this by trading resolution vs color, so memory bandwidth is the same. Look at the flexibility: every sprite can choose to be monochromatic or multicolor, zooomed or not independently on X or Y or both.

By contrast MSX VDP has only 1 (ONE! i underline ONE) bit to globally set sprite size. Was It SOOOOOOOOO wasteful to add this feature as a global 32/64 bit array of write - only register bit on TMS VDP ? The logic on sprite zoom was already here the only thing needed was to make the logic a function of the proper bit instead on a global one. The same apply for the X/Y zooming logic. Instead of make zoom depend on a ONE GLOBAL bit let's take the proper bit at the cost of a minimal complex logic needed to determine if sprite should be on scanline or not. zooming logic is already here.

2) now hw scroll assistance. you need to use redefined tiles, but you have a limited nr. of tiles.... 256 and an omni-dir scroll is somewhat a showstop killer cutting down the nr. of distinct tiles to 32! + you got a lot of vram access than on c64 is NOT NEEDED to scroll 1px in somewhere direction!

the sadness is that most of the concepts in VIC-II chip are taken from the VDP only improved in a clever way

and i can think that the rapid market invasion was not succeeded.
Why ? because when a young people see a colorfull smooth scrolling screen shot from the VIC-II on c64 of a game and a blocky scrolling + monochromatic sprite flickering one on msx what do you think he likes more ?
what computer model do you think he tried to convince his daddy to buy?

The 'high performance' c64. (that under the tech point of view is not so high performance. But is has the major advantage on the VIC-II)

Not a very strategical move. Especially considering the high quality level given by electronics manufacturer involved on msx like yamaha, sony, philips, toshiba.....
;-)
i can accept z80 (good cpu and diffused)
i can accept PSG (decent and diffused)
i cannot accept VDP ( old, obsolete, and not arcade wise diffused)

yzi: that analysis is very insightful! Never looked it it that way. Very plausible!