First off-- The code cleanup has gone well. Aside from being better structured, it now supports multiple sensors. Right now 6, but trivial to add more. Here's a short dump of the angles being captured:

The first thing to note is that sensors 0-4 appear rock solid. But, if you look closely at sensor 5, the X and Y values sometimes flip. Obviously not good.

I haven't root caused this yet. My initial thought was that it's due to the interrupts piling up for all six sensors when the initial sync pulse (a.k.a. OOTC) is sent. From the docs, it takes 12 clock cycles from an interrupt being asserted in hardware until the interrupt service routine (ISR) code starts up. No mention on how long it takes to return from the ISR, but certainly at least a few clock cycles. Let's assume that the entire ISR takes ~20 cycles to enter, run and exit-- it's a good ballpark figure. Then, if 6 interrupts are asserted at once (as happens when the OOTC pulse is sent), then the 6th interrupt will be serviced ~100 clock cycles later than the first interrupt. At 84MHz, that's ~1.2us. While that could be substantial for causing drift in the measured angles, it probably isn't enough to be causing the error above. (note: We'll fix the above issue by reading the OOTC pulse with only one sensor-- it's a lower priority for now, but will be necessary before we're done).

So, another interesting observation is that when this bug hits, X and Y are swapped. That's particularly odd because X and Y are acquired completely independently. It's hard to imagine an issue that would always affect both of them. This should be an interesting issue to root out.