If the fix for this involves recoding how MFC handles patch changes, I have a request that may go along with it:
Is there local memory in MFC to store a hash of patch numbers and names and then scroll through this rapidly on MFC, and only load the patch change 500 msec after button release? Heck, if you want to preempt people complaining about the time to change just one patch, make it an MFC config option for how long to delay on button release before triggering the actual patch change.
That would stop all the weird glitchy artifacts where it seems to load each patch in full with the associated transmission latency while just trying to scroll through them. Would cut down a lot of data transmission and processing cycles and improve user experience, while reducing corner-cases that need to be handled on AxeFx side where it half-loads some sysex for a patch and then gets a different set of sysex for a different patch while the user is scrolling on MFC. I obviously don't know the details of how you have coded it, and am probably not aware of what other constraints you face, but just thinking out loud in case it's a fresh perspective.
The product is truly awesome, and I hope all feedback is seen as our desire to make it even better.