Since this means reading out hundreds of pages of (quite a dull) documentation, that is quite an effort. What I'm trying to change here is that I want to give people the "big picture", so that they can then dig in to the details when they need to. This means that all the things that I write are not absolute facts, but I've put very much effort to avoid giving impression that they would be while they are not.
It is for this purpose that I created this page. 
It must be as simple as possible and contain only the essential.
3. No speculation, and simply state that mapper registers must not be read according to the standard, backed up by the facts that some mappers can not be read, others do not read back all bits, and some computers block reading of external mapper registers. Ample reason without having to guess the underlying motivation.
I don't like 1 at all. Please quote supporting official documentation which confirms this to be true, I think this internal/external stuff is purely someone's imagination, presented as truth throughout the wiki page and spreading the myth. Fake news! 
No. 2 is too soft, first saying they are readable (not always true), presenting missing bits as mapper implementations having bugs ("unhandled"), and merely recommending to "avoid" reading them (the rule should be clear: do. not. read.)
Imo, the real reason is reducing cost & bus conflicts / stress if multiple devices respond at the same time, but this is again speculation unless someone can find this mentioned in some official technical manual.
3. No speculation, and simply state that mapper registers must not be read according to the standard, backed up by the facts that some mappers can not be read, others do not read back all bits, and some computers block reading of external mapper registers. Ample reason without having to guess the underlying motivation.
In fact, the standard is not so precise until MSX-DOS2. The fact that some computers block reading of external mapper registers rather confirms the first explanation. This one comes from a document that I can not find anymore.
I don't like 1 at all. Please quote supporting official documentation which confirms this to be true, I think this internal/external stuff is purely someone's imagination, presented as truth throughout the wiki page and spreading the myth. Fake news!
This does not prove anything either.
No. 2 is too soft, first saying they are readable (not always true), presenting missing bits as mapper implementations having bugs ("unhandled"), and merely recommending to "avoid" reading them (the rule should be clear: do. not. read.)
No. 2 is a reflection on my part but you are right. The 2 least significant bits are not necessarily correct if we take into account the mappers without readable registers.
Imo, the real reason is reducing cost & bus conflicts / stress if multiple devices respond at the same time, but this is again speculation unless someone can find this mentioned in some official technical manual.
I think the real reason is that the Memory Mapper has been poorly standardized. The status registers should have been on all MSXs from the second generation with all the bits active. This would have avoided all problems, reduced the costs of Ram expansions and simplified the programming.
3. No speculation, and simply state that mapper registers must not be read according to the standard, backed up by the facts that some mappers can not be read, others do not read back all bits, and some computers block reading of external mapper registers. Ample reason without having to guess the underlying motivation.
In fact, the standard is not so precise until MSX-DOS2. The fact that some computers block reading of external mapper registers rather confirms the first explanation. This one comes from a document that I can not find anymore.
Doesn’t really matter when the standard became precise… Since proper BIOS mapper support routines were not introduced until MSX-DOS2 (royally late), it makes sense that this is one of the first places where it is specified very explicitly.
Additionally, the MSX Datapack appendix A.4 specifies that I/O ports FCH-FFH are write-only.
And for good measure, the TurboR Technical Handbook states that FCH-FFH should always be accessed through the (extended) BIOS.
Now unless someone can find sources of information which specify that “only registers of the internal Mapper are meant to be readable”, this claim should be removed.
I don't like 1 at all. Please quote supporting official documentation which confirms this to be true, I think this internal/external stuff is purely someone's imagination, presented as truth throughout the wiki page and spreading the myth. Fake news!
This does not prove anything either.
I don’t think the burden of proof lies on me.
Imo, the real reason is reducing cost & bus conflicts / stress if multiple devices respond at the same time, but this is again speculation unless someone can find this mentioned in some official technical manual.
I think the real reason is that the Memory Mapper has been poorly standardized.
That may be right, and we’re free to speculate about the underlying reasons, but my problem here is that it is presented as fact that there is some distinction between internal and external mappers, and that the former should have read-back while the latter should not. This comes from the imagination of the author and should be presented as being speculation or even better not be presented at all and remain in forum discussion threads.
The status registers should have been on all MSXs from the second generation with all the bits active. This would have avoided all problems, reduced the costs of Ram expansions and simplified the programming.
It wouldn’t have reduced the cost of RAM expansions, because readback is not needed for standards compliant software. It would have increased the cost of MSX2 computers though. A mirror can be maintained in RAM and this is what the DOS2 mapper support routines do. Wishing it was readable is the same as wishing the VDP registers were readable. A nice wish, but not the reality.