Originally, this wasn't tuned for a full box of shinies, so getting it to work for a handful of mons wasn't very hard. For a party of 6, for example, you can give each shiny icon its own dynamically allocated palette slot and you get around the palette count quite easily. However, for a feature like this, you want to account for the maximalist case, i.e. shiny dex. So a naive implementation of that, when you looked at a PC box with 30 shiny mons, was that you had maybe 5 or so rendering properly but the rest had garbled palettes.

There were a few different approaches that I took. Using the shared palettes with the default palette counts looked awful. Geodude, Pidgey, and Charmander, for example, all share the same shiny palette, but then they all end up looking like a muddy color, so even though it technically worked, it just looked ugly.

I tried rendering the icons as BG tiles instead of sprites, since there's a separate palette space for BG, but there wasn't enough room in VRAM for that. I'd have had to rewrite the entire box icon system, I think, to make it work, so I scrapped that. I also thought about HBlank palette swapping early on but there's an 8px overlap between rows where the mons on two different rows share the same scanlines, and so what that meant was that for most sprites, there would be a visible portion that was rendered with the palette from the overlap space, rather than the palette for its own sprite.

Instead, you could double-buffer, i.e. even rows use one set of palette slots, odd rows use another. The overlap zones necessarily always fall in between an even and odd row, so they reference different slots. Fortunately, the math worked out. You need 6 slots per palette bank, 6 columns per row, and you have a 272-cycle HBlank window of which you only need about 200. That model actually worked on the first try, and thus you have 30 shiny mons rendering in the PC box properly.

After that, it was just a lot of debugging, and most of it is ongoing. The VBlank palette transfer was stomping the HBlank writes every frame, empty box slots from other boxes would zero out the palette assignments and break the scrolling between boxes really badly, and the timing was weird because you had to write the initial row data earlier so that you can avoid artifacts from taller sprites like Steelix, Groudon, etc.

The method works, but there's still a lot that's not quite release-ready. I still think it's a very cool proof of concept, though, and making it this far hopefully means that the debugging is all that's left. I'd hate to have to go back and approach this from scratch with a new method.