What if the game was designed this way? This very common on closed hardware. For example, early C64 games used a bug in the SID sound chip to generate certain audio. When Commodore fixed the chip, those games became partially incompatible.
That's for consoles back then. The purpose behind such actions was generally to get the hardware to do more than it would otherwise be able to.
Here, there's generally no need for that. We're not even allowed to touch the CD/DVD drive directly (except when Sony lent a hand to some developers for anti-HDLoader tricks).
But that being said, there are some games that (unfortunately) rely on some characteristics of CDVDMAN's APIs. In such a case, we do shape OPL to emulate such traits and that is also the premise of OPL's CDVDMAN - to be a drop-in replacement for the original.
For example, some games like Shadow Hearts 2 somehow were made under the assumption that the CDVDMAN will never actually issue a callback too soon, after the command is issued. So we changed our CDVDMAN replacement to make the callback a little later. None of those were deliberate moves, out of a need for performance or additional functionality, however.
If people feel like fixing game code, then great, but if we can emulate the CDVD and these game become fully playable, just like on the real CDVD, then what's the problem with it?
It's okay. In fact, that is why we have various compatibiltiy modes.
I just have concerns about the direction you're taking for this. If you only stay focused on finding the zen reading speed regardless of what the problem really is, it is possible to end up not improving game compatibility too much and also needlessly worsen performance - which is also one reason why we have OPL (to kill loading times).
When I started PS2 development, I didn't really have anybody to guide me. When I started work on PS2ESDL, I totally had nobody to help me at all.
So when I can still lend a hand to keep you guys from wasting time by wandering down the wrong path (likely because I did), I want to do that. If I had the resources to even help you guys fix more games, I would have done it as well... but doing that is incredibly expensive. Especially when you consider that the development team's QA could not find it, and/or they could not fix it.
For the record, I did waste a lot of time once, thinking a lot of these games really had problems due to speed. Castle Shikigami 2, Disaster Report, Beatmania 16. Castle Shikigami 2 was a particularly expensive case because I actually poured in resources to understand its sound driver's weird design, despite perhaps not being the best in MIPS reverse-engineering. But none of them had actual problems with reading speeds.