So, an improvement could be the multicolor sprites, but that one, comes at the cost of having 8px wide sprites.
I already consider 16x16 pixels sprites rather limited, so having 8 pixels wide area involve to arrange more sprites/scanline, loosing the advantage or more sprites/scanline.
Well. Most people would use at least 2 sprites for an enemy enabling 3 colors on a line for an object. So I do not see the (dis)avantage.
the disadvantage is clear: teoretically sms vdp would allow 8 sprites/scanline, multicolored. this appear as a advantage over the V9938 vdp. Pratically you loose this, because one very often need more than 8 pixel wide area. So what do you do? you place two sprites on the same scanline. in this way you get a multicolored 16px wide sprite on the sms. But in this way, you can have only 4 'logical' sprites per scanline. like on V9938.
So the SMS model is a bit better if i have a game that uses small objects (like bullets). I can have the beauty of multicolor bullets, without being limited to apply multicolor on a scanline basis.
If, on the other hand my, weapon is a sword, so a wide sprite, that could be of only 1 color, the V9938 model is better, because i use only 1 monochromatic sprite instead of two, always required on SMS.
The others situations, are somewhat equivalent. The majority is always the case of 16x16 pixel multicolor sprites.
In that case i need two sprites both on SMS VDP or V9938 VDP
This is the reason for me to say: 'I do not see a big improvement'. For me is much more an improvement the abilty to encode color information directly in sprite pattern table. (SMS vdp)
This allow a more logical management of sprite patters, together with colors, and avoid the need to push 512bytes every frame for ungly color informations.
I do not want to turn this into a SMS vs MSX discussion. It's all about personal (dis)likes.
Luckily it is up to us individuals to decide what we make and for what platform/specs.
Me too. It's a point of view. 
And a side note: the V9938 has no bandwidth limitations in active area when used with a z80@3.5 mhz.
Time ago i've pushed data to vdp with a bunch of outi statement, while in active area, with a blitter command running, and 32 sprites on screen arranged as a grid of 8 x 4 sprites. I can confirm that there is no corruption. the vdp was operating at 60Hz
The bandwidth limitations only apply to TMS VDP.
This is an interesting topic indeed and like ray2day i have been following it from the start
I am really interested in making a game someday for the MSX 2+ or Turbo R, because msx2+ was the system that played a big part in my life when i was young. Like said earlier, I think this is the reason not everyone likes the MSX2 or 2+ even, because they grew up with msx 1 instead.
I wonder how the asian msx scene is like? I dont see much news regarding any recent games from there? which kinds of surprises me since from what I read japanese people are very active in the homebrew scene (called doujin over there) on pc and some consoles like dreamcast.
Though I am at the moment focusing on art (mostly practicing drawings and sprites atm), I would expect my first game to be finished in 10 years or so, maybe at that time there will no longer be any working turbo r's left
I don´t know, if everybody has understood my words correctly. If somebody starts to talk about screen 4 msx2 game and I happen to like that game idea, I will probably just try to get some talk if it would be possible to make BOTH msx2 AND msx(1) versions, because in theory you can convert screen 4 game to run on screen 2.
I have not said anything like "do NOT make msx2 version", like some people seem to read my words. But I guess that maybe it is just so that some MSX2´ers see RED if someone dares to mention about possible MSX(1) conversion of some MSX2 project, because they fear their MSX2 game will get cancelled if someone starts to talk about MSX(1) conversion. Right?
Just let everyone to speak about their ideas, ok? If you do not like somebody´s ideas, do not read it. Ok? 
I did understood your words correctly. 
did you search?
ok... start here: http://map.grauw.nl/
*edit* mind, that learning to become a (MSX) programmer is a very arduous task. Add a hundred more 'very' if you're not motivated or much interested in the topic. (oh, and I mean ASM or C+inline ASM. Not BASIC)