Sparked by the question: What is coreduetd?
This got criticised for being: "it’s also a canonical question for one we want to close as “too broad” and “too wiki” - we don’t want to encourage questions that lack a practical question to be solved and we certainly don’t want to write a “macOS system internals” book one chapter a time and one daemon a time. I’ll refrain from closing from now - but there are fundamental problems with doing this systematically"
Compared to other canonical questions, like the whole section of
this policy seems to be in need of clarification.
Compared to What is on topic here? the question in question is about Apple software, and not matching the section of "refrain from asking".
Compared to "Don't ask" the question in question is "a practical, answerable question, based on actual problems", "I would like others to explain…". It is not like "What are all those daemons doing under the hood", that would indeed be too broad for one question.
And since actual official documentation on this and similar processes seems to be lacking, most of the points under "subjective questions" could also be applied.
The actual problems that will be solved by answering these kind of questions will be indirect but important: can one safely and reliably disable such daemons through the Apple way (GUI, defaults-write, launchctl, other command line tools provided by Apple), unofficial to unsupported means (like deleting essential files, using 3rd party programs), just blocking net access. Are there potential benefits or disadvantages, increased or decreased security, privacy implications.
Currently I think this is perfectly in scope, if the right balance is found. For this balance (=no complete book about sys-internals) I would suggest to define an "atomic level": "sub-atomic" would be that not every single file on a stock install shall have an entry, and "atomic threshold" that every daemon and any higher level process shall be named and explained (as a goal and thereby be on topic).
Currently I think this is tremendously useful to document, learn, educate, and enable users: to alert them to trouble, to calm the paranoid, and generally much more informed decision making.
I am mildly OK with a consensus that says "not for us", but if that is the case I would also like and hereby plead to have updated help center entries reflecting this with a much clearer definition.
In the meantime, what are the fundamental issues and difficulties of this approach?