A bit late to respond here...
...but yeah I have been pretty busy with Batterycheck and getting the game engine running on all the platforms. But since I released the preview versions on the important platforms I could take a little break and do some hardware stuff like this. That is after all the whole reason I started wrinting homebrew in the first place.
How did you get the idea that the Memory Card slot is not a high speed interface? On the
YAGCD pages you can see that the Broadband Adapter is connected on the same EXI channel as Memory Card Slot A! It's true that there is also a much faster HighSpeedParallel port on the bottom which you could also just label as the GameBoy Player connection since that is the only device that has ever come out that uses it. I do have to agree with you on the maximum speed that might be possible would not be much higher than 16Mbit, but if you consider the speed of USB 1.1 or USB 2.0 Full Speed which is only 12Mbit I do not think this connection is really slow.
From what I have read about modchips and in this case the XenoGC clone made with an Arduino like chip it changes the firmware in the drive controller through the debug interface. Yeah I know it's actually an Atmel ATMEGA8 but Arduino is a better known name. This is what makes the drive accept disks from other regions and even burned disks. The clone also has a way to include a small menu DOL in the firmware that can be loaded at certain times to configure some options I think. While really awesome this method is limited by the truly low speed of the drive debug port and the small 32KB flash of the ATMEGA chip. Just replacing that with a raspberry pi is indeed a waste of the potential but it does eliminate the small storage issue with it's huge SD card.
My idea is not to replace the "drive chip mod" but to use a homebrew loader that will can acces the Raspberry Pi hardware devices through special drivers. This would give you for example: SD Card storage, USB Host, WiFi, Bluetooth, Ethernet, and if you really want to squeeze the juice out of the berry there is a huge 900MB+ RAM space that is not in use! It's true that he EXI bus is really just a very fast SPI port (compared to the XenoGC or an arduino) and I was hoping the Raspberry Pi board had the SPI slave pins exposed on the board. I know the SoC is capable of this because it is in the documentation but I read somewhere that the required pins are not exposed on all revisions. There is definitely no driver written for this mode yet, but with the datasheet that should not be that much of an issue.
I know this will not be easy and it will take a very long time to develop and test every bit of it. If you look at it from a higher level it starts with a physical link layer to transfer data between the gamecube and the raspberry pi, preferably at high speeds but if I have to use a 56k serial connection to get started I would even consider it! And I passionately HATE RS232 serial connections because they are slow and unreliable in my opinion! When the pysical layer is working you get the data layer which can send data in both directions. On top of that there would be low-level interface code that will make it possible to write drivers on the PPC side that access the Rpi peripherals as mentioned earlier. Maybe for some devices it would make more sense to do some of the transfers on the Rpi CPU because we also have the issue of an endian conversion going on between them.
Assuming that last part is going to be realized at some point it should be a matter of writing the necessary drivers that will extend libogc for example to see the rpi SD card as an "rpi:/" prefix. And since Swiss is open-source the same drivers could be made to work and compile a custom swiss that would work with that new hardware.
i know it got way to long but hope I was not to technical and you get the idea I have for this project.