You're not taking what I'm saying in the proper context, and you're working under the assumption that I would agree on his choice. You did not understand my reply at all, as you seem to lack any understanding of the environment under which homebrew is executed.
Son, if the issue with changing the INI file in his silly tinfoil pack is that a restart would be necessary, then that same issue lies with replacing CFW files. If you agree with that, then you didn't understand my post that you were replying to in the first place, and we're in agreement. Since you were replying to me to start with, the context is decided by what *I* was talking about.
I do not wish to spoon-feed people with my opinions and arguments, as I am trying to debate with you under the assumption that you have a minimal amount of knowledge and experience working with devkitPro's toolchains, should them be for Switch, 3DS, Wii U, DS, Wii, GameCube, or any other console.
I haven't dev'd for the Switch specifically, just the Wii and 3DS; I don't appreciate the condescension, for what seems to be a disagreement based on your choice of phrasing, and the circumstances of which you entered the thread, rather than knowledge on anyone's part.
Same this as the first point: you do not understand the context in which I said that. Should I reiterate: I do not agree with this decision and I do not believe that "hijacking" the configuration of an user's firmware modification is a proper way to do things, or should ever be. Homebrew should run under original firmware, or under original firmware with minimal modifications.
The context I'm operating from is that you entered the thread seeming to defend blawar. Since you don't agree that hijacking a user's CFW to make modifications is acceptable, while I'm puzzled about your initial style of entry into the conversation, we agree -- which seems to be the only context I was not understanding. Regarding the dev documentation, because it's a Wiki, I have no way of verifying that any of that is official, and having not worked with the Switch ABI myself, I can only go off of what I can verify. If the Atmosphere devs are not sticking to what they agreed to, and an NRO is not able to function in a clean codespace, that is problematic. Without familiarity of the politics at play here, I can't say what the best way to approach that would be, but I do still thing something should be done about it. Which, like you said, good luck.
CFW lists are not possible, as there can be as many as possible, and is not future proof. Plus, if one thing breaks or differs from original firmware, how can you be sure that any of the other things won't? The burden should be on the firmware modifications themselves; as it is completely safe under original firmware, which is the ground truth.
Our difference here seems to be prescriptive vs descriptive reasoning. I think whitelists are feasible. They are not future-proof insofar as they require updates (or at least config updates) when new CFWs are released, but you can ensure that the environment you're working in is exactly as you expect before making potentially bricking changes. I understand, and generally agree that CFW should function as OFW does, however, I see use cases for the changes here. Referencing the ABIs and the way things ought to be is of 0 use when you're bricking people. It provides no remedy, and no reassurance to anyone worried about the state of their console, especially if the firmware devs are resistant to change, as is repeatedly claimed in this thread. That is the prescriptive thinking. Coding based on how things actually are is far safer, even if one has to do more to achieve it. That is how I would do it. But also, I wouldn't hijack someone's firmware, so blawar and I clearly have very different philosophies.
Anyhow, if you're not arguing in favor of blawar, I'm very confused by your approach, your phrasing, and your insistence on rebutting folks who... apparently agree with you? In any case, most of us commenting here are trying to establish that what blawar's done in this release doesn't make any sense, is requiring more work from himself for something he purports not to support (which would actually be better for those who use it anyhow), and that exits the scope of what a single app ought to do. I'm glad we agree, and thank you for your work on tinfoilmod.