I removed the limit of 9/10 active MDUs in the 2016 branch thus removing some display mixing problems from the system.
But in the process I found out that this problem is not totally fixed: if we change the VC position too fast, the CRTMFDs seem to not have enough time to reload the previously saved display ID, thus when changing VC position, again, they still have the default display ID loaded (the "DPS display") so that is what is saved overwriting whatever ID it had before, thus they revert to the "DPS display".
I think we can fix this by moving the display ID (and menu ID) to the MDU, as it probably is (or was) in the real thing. The CRTMFD's single task would be to call the MDU to do the painting and the MDU decides what is painted, instead of the current shared system. As it requires a change in the scenario format, this is a good candidate for implementation in the SSU 4.0 version (still for the 2010 Orbiter), but for the next few days/weeks I won't have much time to it, so if the idea is to get 4.0 out the door ASAP and move to the new Orbiter, and for me it is, this will have to wait or it would delay things even further.
Plus, I've been looking at the new functionalities of the 2016 version and looks like we can have our OV vessel "swallow" the CRTMFD so it's not accessible from anywhere else, so we could group these 2 changes for a SSU 4.1 or 5.0 version.