From my seat, I see the issue as a choice between being right or being happy. M9 is technically being "right," but it results in me not being "happy."
That's a bit like saying when somebody flips a coin and your task is to guess "heads" or "tails" the choice is between being right or being happy.
That's not the choice at all. In games of chance, it is a matter of luck, not a choice between a "right" strategy and a "happy" strategy. When flipping a coin, whether you guess "heads" or whether you guess "tails," you're going to be wrong half of the time.
There is none of this "Oh, the right choice is to always guess "heads" and if people are not happy with that, too bad." Conversely, there is none of this "Oh, I wish the software would make me happy... just guesscorrectly heads or tails all of the time."
Images can be a game of chance as well, when different files use different channel ordering, and sometimes within even the same format, but the format does not say how the ordering should be interpreted.
Many formats do, of course, either by how the format standard is written or because of a standard tag or standard sidecar file that says "this is how the channels should be interpreted to form a visual image." Those are not games of chance, and in such cases there is no need for the software to guess or to make any distinctions between "right" and "happy." The software simply does what the standard/sidecar/etc says, gets it right, and everybody is happy.
The problem is "games of chance" formats, or people who wrongly implement standard formats: If the format does not tell you the channel ordering that is supposed to be used (and most of them do not do that), you have to guess. Whichever way you guess, just like flipping coins, sometimes you will get it wrong.
You see that especially when interoperating between different packages, because poorly-written packages that utilize poorly-specified formats often depend upon secret handshakes, and not explicit standards. They may be completely unconscious that other software operates differently, that standards exist, etc..
Example: Billy Wilson has written his own image editing program. He used a library he found on the web, he can't remember where, to read/write data to what he calls TIF format. He's pretty sure this has something to do with the "TIF" format he's heard of but maybe it's something else. But what the heck, he's going to call it TIF anyway.
Billy's new program saves channels in RGB ordering because he's heard that "RGB" images are what they are supposed to be. The library Billy used is set up for BGR ordering, but Billy changed that as an obvious mistake. The library mentions something about "tags" but since Billy doesn't know what those are he ignores doing anything with them and just lets the library do some sort of default thing with them.
So Billy's program floods his users with many, many images that have channel assignment backwards from how the library he used is supposed to work. For added chaos, Billy's program writes tags that explicitly say the channels should be interpreted differently than what they are. Think Billy cares about that? Nope.
In Billy's program they work fine. In every other program that uses the library the colors are wrong. Billy's thinks that because his program works great he obviously got it "right". His users are "happy" because when they use Billy's program everything works correctly. They get on the web to criticize all those horrible commercial programs that aren't free like Billy's, and which get it "wrong."
The above example is extreme but common. Also common are programs that use "popular" formats for images which do not contain bogus tags, but where different channels are used for different types of data. It is extremely common for programs to write particular channel orderings and then, because they assume it should be a particular way, the data works within that program but not necessarily with other programs, which take a different approach.
To interoperate with all that a program, like Manifold, has to be able to consume data in any channel ordering and to interpret that data however it should be interpreted for the data to make sense for the intended purpose, such as creating a visual display where the colors look right. That's the easy part.
I emphasize that in what follows the problem is not well-defined formats for purely visual images where channels are always in a well-defined order and intended interpretation, or formats where tags/metadata are correctly used to specify channel order and intended interpretation. The problem is the "coin toss" formats where different interpretations are possible or where tags/metadata are incorrectly used. That's Billy's World.
The hard part is what sort of user interface you want to interpret different arrangements of data. The key thing to understand about that is whatever you choose will make some users unhappy. There are two approaches:
1. The classic Windows consumer approach is to deal with a reduced number of formats and to automatically interpret different channel arrangements on a "best guess" approach that works well most of the time for those formats. This is basically sticking your head in the sand and wishing the problem away: "Oh, no problem! I'll just stick to reading those formats where there isn't any problem." That works great if you have a limited number of consumer formats and you only read files that use them correctly.
The price you pay for that approach is that it breaks down if you can work with many dozens of formats, and hundreds of sub types, like Manifold can do. Doing "secret handshake" changes behind the scenes based on what the program guesses will inflict chaos on skilled users by sometimes making changes in interpretation and sometimes not.
Manifold used to take that classic approach, modifying interpretation in a "best guess" way. That made some people happy while other folks were unhappy. So, now Manifold uses...
2. The other approach is to import the data as it is and allow whatever interpretation the user desires for displaying that data. In cases where formats or tags/metadata specify an interpretation, use that. But otherwise, leave it up to the user. If you want to be "happy," do whatever you like so you can get your way and be "happy." There's no being right or wrong, just let the user do whatever they think means "happy." If somebody isn't happy, it's easy to change to what they want with everything being done up front, totally transparent, no guess work or second guessing anybody's second guesses.
Using that approach leads to more certain success with Billy's World or other problem formats, as well as for the very, very wide range of niche or specialty formats that use variable channel ordering/interpretation. But it does so at the cost of annoying less skilled users who haven't learned how to work with such variety, or who want to do more advanced things with varied data than their current level of learning supports.
In such cases, for example, if a user wants to merge different data from different sources that use different channel orderings and/or different interpretations, well, it's up to the user to make whatever decisions or alterations they want before merging.
You can, of course, wish for a super-duper merge tool that combines both merge functionality and interpretation editing capability into the same tool, putting controls for such alterations into the merge process. Whether you think that makes sense or not depends on whether you want the same functionality duplicated in different places, or whether you believe that user interfaces are easier to learn if they stay modular, without many different dialogs trying to duplicate the work of other dialogs and thus adding to complexity.
There are many cases in GIS where merging different types of data requires some thought and skill on the part of the operator. That's what you get when you allow the great variety and richness of data sources that something like Manifold provides. The good news about images is that they tend to be very simple compared to other "merge different things" tasks.
For, example, suppose you just want to merge files of city names and locations from many different countries into one table. There you might have to deal with the fun where the city name/location tables provided by different countries might use completely different collations for the Name field, for example, a Portuguese Brazilian collation from one, a Spanish Mexico in another, a German Swiss collation in a third, a French France collation in a fourth and so on. How do you combine so many different sort orders for different languages into a single field in a single table?