It’s kind of messy due to the way the bootstrap gets mapped in. The LR35902 CPU core is screwing us over in two ways. It effectively implements GBC fast/slow mode as a multiplier rather than a divider (internally dividing the cycles per opcode), and it does bootstrap accesses via the program space. This means we can’t properly expose the phi clock to cartridges for things that depend on it, and bootstrap accesses are exposed to the bus when they shouldn’t be.
The most obvious side effect of the latter is that taps don’t work right at boot time. An address space tap on the program space shouldn’t see bootstrap ROM accesses, but it does, so cartridges need to use trampolines rather than taps for monitoring bus accesses during boot.
Then you add to this the mess of how start, load and reset work. All the devices besides the root machine are started before media images are loaded, but reset happens after everything has started, and hence after all the loads complete.
Whichever way you do it, you’re likely going to end up with your view interfering with the view used to map in the bootstrap ROM, which of course shouldn’t be using a view because it isn’t accessed through the address space in the first place, but doing it properly without going through the address space and also not having to do a test on every memory access (hence tanking performance) would require substantial work on the LR35902 core.
Then you have to consider whether the cartridge in the piggypack slot can see accesses when the GameShark has its own ROM mapped in, so taps work correctly.
TL;DR I don’t think it’s going to be easy.