The problem with library authors in general is that they, on average, have a better perspective how client programs should be written. Writing a good library is generally far harder than it is to use a good library, and musl is pretty decent so this remains true: most users of musl have far less technical skill and a more myopic view than Rich Felker does.

But, as is true of libraries, and programming languages, and life in general, there is always someone smarter than you are, who genuinely needs to do the thing you say people should generally not want to do. This is why taking a moral stance of "not" allowing the thing is almost always the wrong approach: what you want to do is make the non-recommended path unattractive to a casual newcomer, or have sufficiently good education and guardrails in place that people don't stumble upon it, but there has to be a way to do the non-recommended thing. If you don't, the person who really needs it will find a way to do it anyways, and probably curse your name the entire time.

Anyways, bringing this back to musl, I think it takes an agreeable stance that it follows POSIX (plus some stuff that it couldn't really leave out, because it breaks too many programs). Cool, it does a good job at that. But sometimes people, who are aware of the user-agent problem that musl is trying to avoid, would just like to make a special codepath that lets them use some more optimized, nonstandard thing that musl doesn't support. If you need your static initializers to get argv, then there isn't really much you can do but provide a macro for detecting musl. So provide that macro, name it THIS_IS_MUSL_BUT_MAKE_SURE_YOU_KNOW_WHAT_YOU_ARE_DOING or whatever, but make it available for things like these. Sometimes practicality has to win out over idealism, and musl contains a bunch of those tradeoffs already: this should be another one of them.