Messing around with a ME7.5, I have found out that it supports both KWP1281 and KWP2000 in a strange way.

It only seems to support 5baud init.
When sending address 0x01, it sends keybytes 018A and starts KWP1281 communication.
With address 0x11, it sends EF8F and starts KWP2000.

The thing is, in every specification I was able to find, odd parity is imposed for the address sent at 5baud. This implies that actually 0x91 should be sent in order to target address 0x11.
But this ECU will not wake up when sending 0x91.
As such, VCDS can only connect to it in KWP1281 mode, it fails to connect to 0x11 ("Engine II") since it is sending 0x91.
I tried looking through ODIS too, and EnginContrModul2KWP2000KLINE has CP_5BaudAddressPhys defined as 0x91 too.

What am I missing?

Well, it's not that it responds to KWP1281, rather with KWP1281

Like, how are you supposed to know that you need to send an "incorrect" 5baud address to access KWP2000? Is it supposed to be a hidden mode?
As far as I can tell, there is no way to get KWP2000 on this ECU using standard test equipment, as it will always calculate the parity bit and send the address as 0x91, to which it doesn't respond.

Then this ECU is a counterexample, since it "responds to" KWP1281, yet diagnosis can run on KWP2000 just fine.

It's a much more plausible explanation, but I feel like that's not all...

I know I'm starting to sound like a broken record, but the main point of my question is why does the ECU insist that 0x11 be sent with a purposefully wrong parity bit?

Like, is there any specification document, like a Funktionsrahmen for any ECU like this one, where it outlines that 0x11 must be sent in 8N1 data mode instead of 7O1? I mean, 0x01 and 0x10 too, but those wouldn't have an odd parity bit added anyways.

Hm, that sounds a bit more sensible for a way of switching between KWP protocols, instead of sending a mutilated address byte

Yeah, but I assume those are implemented according to spec, i.e. 0x91 is actually sent for slave, so that VCDS can connect too.