But Grauw I have a question for you. What if such Turbo-R/V9990/OPL4 OCM existed but had improvements over the Turbo-R:
-A much better transfer rate to the VDP?
-What if running z80 code it could be as fast as a Pentium 100?
-256k Vram for the V9958?
I want to answer too. 
For me FPGA and emulators that have different performances/behaviours are a problem when I develop programs. We believe to make a good program but this one does not always work on the real MSXs.
-Had no limitation in terms of number of sprites?
I think it's a good thing if we have the possibility to select the normal/enhanced mode.
- A DMA to transfer from the SD card to memory at 10x the speed?
It's interesting.
- Play PCM samples? Transfer to the VDP?
-Longer buffers for the MIDI interface, maybe using the DMA as well for buffering.
This is not interesting because I do not think it is feasible without maintaining compatibility with what already exists.
-What if that Z80/R800 cpu had hardware division? Or floating point?
That would almost not used because the software that would use it would be very specific.
But Grauw I have a question for you. What if such Turbo-R/V9990/OPL4 OCM existed but had improvements over the Turbo-R:
-A much better transfer rate to the VDP?
-Had no limitation in terms of number of sprites?
-256k Vram for the V9958?
-Faster commands? Maybe polygon fills?
-A DMA to transfer from the SD card to memory at 10x the speed? Play PCM samples? Transfer to the VDP?
-What if that Z80/R800 cpu had hardware division? Or floating point?
-What if running z80 code it could be as fast as a Pentium 100?
-Longer buffers for the MIDI interface, maybe using the DMA as well for buffering.
Not interested in any of that . If I’d make use of any of that it wouldn’t work on a real MSX anymore. I don’t see the point in writing any software for things beyond what the turboR can do with real hardware expansion cartridges. Already I really prefer to support the lowest of MSX1, 2 or 2+ if the project doesn’t need any more, to get the largest target audience, and I guess this applies to most people, which is why there’s so few turboR and 2+ software around.
In some cases you could argue that a program could make use of something if it’s available and fall back on something else if not. Progressive enhancement. But it introduces extra work, and really usually you have to write for the lowest common denominator and make it performant there, so if that’s already performant there’s not much point in writing special code. E.g. my game project is designed around the speed and VDP capabilities of the MSX2+, so running it on turboR has 0 benefit, nor would divide instructions or extra VRAM or uncapped sprites or faster commands.
FPGA like the 1chipMSX to be honest is really more of a hassle than a benefit from a programmer’s point of view, since the emulations will be imperfect and the software has to work around it. Both VGMPlay and my game project suffered from that, though luckily KdL has been very receptive to bug reports, but they can be time consuming to research and tricky to resolve. Emulators have the same problem of course, but the development team for e.g. openMSX is much larger and consistently made many improvements over the years, so it puts me more at ease (also I use it daily).
But if FPGA would make the turboR platform more widely available, so that I could write turboR software with more confidence that there will be a sufficiently large user base, that’s something I would sign up for definitely. And I think there are plenty of people who would like a turboR, and this could give them a more affordable one.
For such a platform, I think an FPGA which just focuses on the MSX-ENGINE / S1990 / R800 and all the rest is implemented with original chips may be even better. Then development effort can focus on perfecting the emulation of the CPU timing and glue logic, timers, etc., and the sound and video chips will be bug-free. AY-3-8910, YM2149, YM2413, V9958, all still available. OPL4 and V9990 cartridges exist so those are really optional for me to have built in, although an integrated V9990 superimposing on the V9958 could probably reduce the number of cables so that might be nice.