The only strangeness I've seen so far relates to the state of CRP/SRP registers for saving/restoring MMU state.
The MMU can throw exceptions if illegal values are written to these registers - the bitfield gets sanity-checked by the CPU before the register is changed.
I noticed the initial value of SRP is garbage on the Falcon and therefore cannot be saved/restored without causing an exception. This should affect all Falcons (and Hatari).
However I found one additional (seemingly Hatari-specific) problem, which results in an incorrect value of 0 being read from CRP, which also causes an exception when restored on exit (but this doesn't happen on real hardware). This operation uses the 64bit pmove.d instruction.
I wondered if it needs to be quadword-aligned, but haven't investigated it properly yet so I'm not sure of the real cause for difference here.
I haven't noticed any other differences so far.
D.