What if V9938 never existed?

Again you missed the point. I've not even told that V9958 can compete with Amiga in terms of blitter power.
Instead i've told the opposite.
My point is that V9938 designers gone in the same direction that amiga designers did.
Instead of pushing hw sprites to the limit by extending colors, numbers etc. they give more power to sw ones, by assisting CPU with blitter. Because they realized that is was the way to go.
The difference between V9938 in terms of philosophy does not exists.
Both system have a sprite system that is more limited when comparing with bitmap graphics.
However the amiga blitter is at least an order of magnitude faster than V99x8 due to some inefficiencies on the latter.

The presence and the need to use copper, only proves that hw sprites were too much limited compared with sw ones.
Otherwise similar results cannot be achieved.

Again the bus width question: It does not count as you think for example the z80 had a 4bit (!) ALU and 6502 and 8 bit one so there is a ALU internal bus of 4 bit in z80 vs a 8 bit one. But z80 is a lot faster in logic/arithmetic operations than 6502 at the conventional speed of the era.

there is nothing stopping you to use both hw and sw sprites combined in v9938 . there are games using it
Of course as on the AMIGA using sprites and blitter causes more slowness on the latter, while on the amiga doing heavy use of the blitter can cause some sprites disappear.

Never told this.
I'm only told that if V9958 where the MSX2 videochip things would have changed a lot because it opened up the ability to use the blitter for things like sw sprites that on the V9938 is not possible to do.

the v9990 is another philosophy. For example, you cannot use the full power of blitter in modes that have good hw sprite support and if you want good blitter support you need to drop hw sprites.

Basically the V9990 gives you specific modes addressing a specific task.
Do you need game oriented features?
you go for P1 or P2 mode. It gives you hw sprites and tile mode that reduces a lot the weight of VRAM size to manage. But it introduce a penalty about the blitter speed.
Do you want a bitmap and sw sprites?
Bx modes have a lot more of blitter power, but forget about tiles and hw sprites. It is up to you to implement that.

MSX2 screen 8 256 colors is not a tile mode. The transfer of the bitmap tiles from main memory in that game can be done just on time because the scroll is slow and CPU has enough to send the information.

Do you believe that MSX2+ was able to do this at same speed and with the same music in 1988?
https://www.youtube.com/watch?v=ZwkrOy9CcYQ

Anyway the point is that this scroll works @256 color without limitations in pixels colors. Even a more powerful AMIGA chipset cannot do this.

PingPong, I have read the article of your link. It's very interesting. There are several point I want to clarify. The memory in A500 works with a frequency twice than CPU frequency (7Mhz aprox.) , i.e. 14 Mhz. Amiga blitter can work at 7Mhz or 14Mhz in Blitter nasty mode (a flag in a port). In this mode, CPU is starved of memory and has to wait for Blitter ends its work.

Floppy disk information is processed by the sound chip Paula designed for 3,5" low density floppies and Amiga 4000 has the same Paula but it has a 3,5" HD like PC. That's the reason for reading HD floppies at half speed than a PC. Commodore didn't evolve Paula in AGA generation.

The palette registers of OCS, ECS and AGA are compatible. AGA has 8 banks of 32 color palettes. Commodore added a new port to select the bank, by default bank 0 is selected.

The author says that the longest sample that Paula can reproduce is 128KBytes. I don't remember but I believe it's true. A few moths ago I was programming Moonsound OPL4, and I have to say that the longer sample Moonsound can reproduce is 64 KBytes. When Paula ends the sample reproduction interrupts CPU giving the opportunity of reprogramming Paula registers to reproduce another piece of sample. Moonsound only interrupts MSX CPU when OPL timers expire. If you want to reproduce a sample with more than 64KB in a Moonsound, you have to calculate the duration of the 64KBytes sample piece taking account the played frecuency. Although Moonsound have two timers with different resolutions (80 microseconds, and 323.1 microseconds). You have to do some calculations and it can be hard to reproduce a long sample without cuts. Paula does this kind of things easier.

One very important thing about Amiga blitter that it is not mentioned by the author is the Amiga blitter only supports copies of rectangular sections with vertical flip (with negative modulus), but Amiga blitter doesn't support horizontal flip :-D. Graeme Cowie or McGeezer, the author of Amiga version of Rygar stores all the poses of all characters looking in both directions because he doesn't have other better option. However, MSX2 blitter can do flip X and flip Y, reducing memory consumption

I do not know moonsound at all, but my opinion is: instead of the way the interrupt the CPU, what is more important is the ability to work in a circular buffer way, that is instead of waiting until the last byte is played and fill an entire block, is there a way to incrementally fill with a small but more frequently sent buffers?
This way allowed to play continuosly an arbitrary length of songs, limited only by amount of ram available.
Neither 64Kb or 128 are a long buffer. If you play in mono at 12Khz and 8 bit for example you use 12Kb/sec. and this is not a so high quality.
By contrast, having a kind of system that allows continuos fill in a similar circular fashion can simplify things a lot.
There is a mp3 cartridge for msx where the decoder is periodically filled in with data from z80 and plays continously songs. Even if we are speaking of compressed data (handled obviously by the mp3 hw) the principle is the same.

About the blitter hog it has its own drawbacks, even if more faster than cpu one could not want to sacrifice the entire cpu for the blitter.
It does depend on the situation.