I started working on some new tests for a strange hardware glitch involving accessing banked registers after loading user mode registers through LDM^.
https://github.com/alyosha-tas/gba-tests/blob/master/LDM/LDM_ALU.gba
The basic effect, described here:
https://github.com/mgba-emu/mgba/issues/2942 , is that reading OR's user and banked registers together and writes write to both sets of registers.
Unsurprisingly, this is extremely annoying to implement. It basically requires an entire separate execution path when the processor is in this state. It's still a work in progress, there are a lot of cases to work through.
There is also a test for this in the most recent AGBEEG tests. But these tests were tested on 3DS hardware which evidently behaves differently as they don't work on GBP.
So far I don't see any games even use LDM^, so this might have low utility, but its a good thing to be aware of (I did check if Snood perhaps encounters this but it doesn't.)
EDIT: Additionally, when I compiled the recent AGBEEG tests the cartridge tests fail on hardware. It looks like I get a different binary than the release version when i compile from source at that commit, so my tool chain must be a little different. Anyway the test passes on emulator but fails on console. I'm pretty sure this is the result of changing wait states, as when I change the order they are checked in, the fails happen in a different way. This is unexpected, and itself another major headache to implement if my guess is correct. But, one complicated edge case at a time.