For the record, that's me - I'm the Director of Education for MuseScore.

The formatting information in a MusicXML file might be detailed indeed, but that doesn't mean it is actually technically feasible for all programs to reproduce all of it in all cases, nor does it mean it is worth the enormous effort it might take to rewrite layout algorithms to accommodate this. For a small open source project like ours, it's a question of priorities. And yes, I am familiar with the code, being one of the developers myself.

Right now, we simply don't support any way to force more measures per system than what would fit naturally given your particular settings for staff size, measure spacing, minimum note distance, etc. So we simply have no mechanism by which we could support a MusicXML tag/attribute specifying a particular number of measures on a particular system. This could indeed be an interesting new feature to add, not just for MusicXML import, but for general use as well. But for now, no way to implement this on MusicXML import without significant changes to the layout algorithms. We can honor system breaks because we have tha feature, but we cannot honor a "fit X number of measures on this system" because we just don't have that feature, MusicXML or no. And the same is true of number of systems per page - we simply have no ability to set this in the program, only to control various parameters like staff size, staff distance, and minimum system distance, that ultimately give you that control. So if a MusicXML file specifies that, we could potentially honor it, but if all it does is say "give me three systems on this page", we simply don't have that facility.

Similarly, we don't have any facility to identify particular systems as optimized or not. We have a global "Hide empty staves" setting that applies to the score as a whole. So again, no way to honor a per-system setting in MsuicXML without significant changes to the layout algorithms.

Instrument changes we do support, via text instructions, which of course the human musician reading the printed score would need as well. You are welcome to make them invisible. I have no idea why your MsuicXML file has so many of these instructions encoded, seems likely to be a bug in the program that exported them since there is nothing I can see in the original scanned image to indicate any such changes. I'd need to see the MusicXML file and understand more about the context to understand.

Anyhow, this is the sort of thing I mean when I say that "in theory" the MusicXML can contain certain information, but in reality, there may or may not be a way to honor it. If the information encoded happens to be the sort of thing the receiving program is equipped to deal with based on its own feature set, great, but not all programs have the same feature sets, so information encoded by one application just might not be relevant for another.

Of course, Finale can generally import the information its own products export, and since they controlled much of the original spec, they also had a say in what others could export, so they'll generally do better than average there as well. Even so, there are likely some things others export they don't handle because it's outside the feature set of Finale itself, and this will probably become increasingly true as their control over the MusicXML spec has become less absolute.

So again, it is indeed true we, along with many others, do not attempt to interpret much manual formatting info on import, focusing more on content.