I talked to Dan Salvato about this, and he gave me the idea to dump MRAM at certain spots and use vbindiff to search for differences. I found that 81500000 to 817f0400 is written to in two cases: a couple of seconds into idling at the title screen (I have no idea why), and during Pokemon Stadium transformations, because for whatever reason PS stage data is loaded there instead of where I've seen most of the other stages load their data (81300000+ range). I haven't checked if single player mode overwrites these values, it'd be a real pain if it did though. I just wrote a code to transfer the alt CSP data somewhere else during the match loading cycle and write it back to 81500000 post-game, so that fixes the problem with PS. As for swapping CSPs, I don't have a code for it yet but I've located the pointers to all of the image and palette data so now I can change any vanilla CSP to an alt CSP just by changing two values in the RAM.
Even if this alt CSP project doesn't work out, I still see applications for loading data via apploader.ldr. There's only so much room in the RAM, but as far as I can tell there isn't a limit to how much data you can append to the end of apploader.ldr. You may find some use for it to place codes in unused RAM space Achilles, though I don't know what your current situation is with extra code space (I just remember you saying that you were putting codes/debug menu stuff at the end of MnSlChr.usd).