If the Pi is snooping every phase of every bus cycle you could copy the
interfaces of standard peripheral cards (Uthernet II for IP, SSC for
printers, video phase of the data bus for native video) and then maybe
Smartport for storage and any new facilities you want to add. By allowing
the one card to logically appear in multiple slots (user programmed e.g.
Uthernet II in Slot 1, SSC in Slot 2, Mouse card in Slot 4, Smartport in
Slot 5, Disk ][ in Slot 6) backed by emulated peripherals on the Pi you
could tap into much of the existing software base and only need to create
new Apple software to take advantage of the new features.
With the user programming of functions to slots, you could even have a
helper program in the Apple interrogate the slots for physical cards and
disallow use of occupied slots to avoid bus contention. If you want to get
really adventurous you could require your card be placed in Slot 7 and have
it subvert the boot process by appearing as a boot device, pushing the
helper program to system RAM as a boot block, interrogating the slots to
identify physical cards, allow the user to decide how to manage any
conflicts detected, and then continue the boot process as normal. That
would slow down every boot, so it might be something you’d want to be able
to disable or only perform when a certain key combination is detected.