Most µCs have an external interrupt pin and a µC that can handle the SPI signal should be able to handle the CS line.
If you are implying that the gating/pass-through be done by the MCU activating/deactivating its /CS to the SDCard when it receives an interrupt from the /CS from the PS2 - I don't think that would be fast enough - the delay introduced will be too great I think, based on previous experience with MCUs. Although my measurements show, that even though the clock is 24MHz (the max possible) there are quite long pauses between bytes and the effective clock is ~16MHz - 2MHz per byte(/CS). Still I think some external gating may be better, unless the MCU has dedicated internal circuitry for that.
When I said to support multiple MCU types, I meant it like - have pinouts for both, on the same PCB area, one slightly offset from the other, still attempting to save as much space as necessary.
Du you think a debugging PCB should fit into a MC case? (I don't think, only the final sollution must fit into it)
Yes, this should be fairly simple, so the debugging should fit the MC case. A multi-color LED can be used or multiple LEDs.
Also that reminds me - the MCU should read the SD Card's Write-Protect switch and send info about that on card-replacement to the PS2. The PS2 driver should save this locally and not send write commands in case it is write-protected.
It would be good if the command that start SD Card communication also has the effect of checking if the MCU has any state info for the PS2 side (like card-replaced or write-switch, or some other fault detected).
Basically it should be decided on some command, that does no harm to normal MC cards or controllers (though controllers never connect to the MC ports so maybe this is not an issue. Initially the MCU should not respond anything and it should only start driving the bus when it detects the particular command data for SD Card I/O start. This is in the case we assume that the same bus can be used for an MC too. But as this is not the case (each port is separate) maybe the MCU could start replying from the start. And only once the driver sees the decided-upon MCU reply should it start I/O. Of course that should be made short too, so that it doesn't waste time.
The selected slot is a push-pull slot, but if the PCB is designed like you explained it isn't possible to replace the SD card through a hole in the case.
Yeah, that won't work for a push-pull slot, but then the card would have to stick-out from the MC and that is all the better for having more space for the MCU inside the MC case.
BTW, I really like how you solved the problem with the LEDs being on the underside of the PCB by having holes above them. I don't think I have seen this exact thing before.
And I don't know if the "scene" is familiar with PICs - indeed they were used for PS1 modchips and later there were the SX28-modchip which is a fast PIC instruction set MCU, but I see more people being familiar with Arduino nowadays.
And although it probably isn't necessary, there could be a capability to update the MCU's program (through the SIO2 SPI again), as some MCUs support a bootloader.