Hah! I haven't really been following that thread so I hadn't seen it. Great (diseased?) minds think alike, or something.
Yeah, the lack of any sort of wait/handshaking signal on the memory bus does put a lot of onus on whatever you hang there to be able to respond in a timely manner...
Well, I think you *could* probably get away with using a couple of fast latches between your decoded bus port (assuming here you're using a microcontroller to handle the SD card and just using the SIMM-port for message passing) and the microcontroller. Basically, what I'm thinking is a couple of 8 bit latches, one for reads and the other for writes, and a little bit of "glue" so:
A: For a read, the Mac would write the byte (via the address line trick) into the latch. Doing so would raise a bit on a status register (which is also "wire speed" from the Mac's perspective) indicating that a byte is waiting is waiting in the buffer, so the Mac has to wait. (that of course implies a polling loop.) Meanwhile, the microcontroller at its own pace can get around to reading the latch. Once it's done so it'll reset the status register, so the Mac can write another byte.
B: Likewise, for reads, the microcontroller writes a byte into the read latch and sets a flag indicating that valid data is ready. The Mac, stuck in its polling loop reading the flag register address, sees the latch is ready, snatches the value, and resets the "valid data" flag. (With a little cleverness presumably you could reset the flag automatically when the Mac addresses the read port.)
Looking at the data sheet for the 74HCT259 8 bit latch (which *might* be an appropriate part for both data latches) the propagation delay is in the 60ns ballpark. That might just do it.