MSX Turbo-R : Unexpressed potential?

The Turbo-R has for sure a lot of unexpressed potential but it is also affected by terrible crappy decisions in its HW design. The I/O speed toward the VDP is the most critical flaw, where in Z80 mode you get an higher bandwidth (!). This means that you have a very fast CPU waiting the most part of the time to the VDP, unless you do acrobatic coding to interleave other tasks with I/O... Also it lacks of programmable interrupts and this makes the PCM audio just a useless frill. The result is that games using it will hang during playback (as the first experiments using the key click to play 1 bit audio) unless you do acrobatic coding to interleave audio with other tasks.

In the end, the potential is well hidden and hardly accessible. Without coding strategies more suitable for demos than to games, you cannot go very far from an MSX2+

For the scrolling for sure.
But I have never seen a title that made me escalate
"Well, this could never have been done on MSX2 / 2 +"

No, as ARTAG was trying to point out is that the Turbo-R architecture goes against sane hardware design: faster CPU won't matter if it is stuck waiting on a lot of stuff. I would even argue that not having a VDP interrupt on command completion in the V9938 was already a major flaw: it means your architecture will struggle heavily to achieve full parallelism between CPU and VDP. Blaming it on the developers is easy but rather unfair

The command speed is rather irrelevant here. What the system needed was a better VDP with better character modes that are more tailored to games. If you look at console hardware around that time you can clearly see the trends there and for good reasons. Instead of issuing complex VDP commands that it needs to wait on for completion, the CPU then only needs to manipulate character IDs in video memory, which is much faster and less convoluted to code.

A partial example for reference: the SNES CPU speed is comparable to that of a Z80.

I did not say that. I talked about the VDP. I said that the biggest problem is its slowness, not interruptions.

I don't blame the programmers. I just note that programmers have always preferred to develop for MSX1 and for MSX2 to a lesser extent. This is normal given that the 2+ and turbo R are much less common or even almost non-existent in many countries.

You are wrong, V9938/58 commands are not complex, just slow. Fast copies (or at least tiles) and better sprites are essential when the CPU is a slow 8bit to make games.

Anyway, there are obviously plenty of things that could have been better, but that doesn't answer Journey's question.

Yes, sure.