The result of musl's attitude is build systems assuming "__linux__ && !__glibc__ means musl".
I pity the compatibility nightmares any new libc pushing for mass adoption will have to deal with. Musl's approach adds cost to everybody but themselves.
Do you have examples of this? What __linux__ && !__glibc__ should mean, in my opinion, Linux but without glibc extensions. This does not imply musl, but does happen to also be what musl aims for, so there is going to be users where either would look the same.
There are more libc's out there than just glibc and musl.
The `backtrace` call is a great example. It is available in glibc and uClibc, but not musl.
Instead of checking if using musl, and removing the backtrace call, the lack a musl define forces you to check for all the other possible libc's and assume musl is the default. This is dumb.
That is probably a bad example. That is a GNU extension, so if handling this via the preprocessor, the right guard should just be #ifdef __GLIBC__, I think. That should cover both glibc and glibc-compatible libcs such as uClibc. (Yes, uClibc does define __GLIBC__ as well.)
I pity the compatibility nightmares any new libc pushing for mass adoption will have to deal with. Musl's approach adds cost to everybody but themselves.