Glibc is obstructive to static linking but musl is not. That gives you a binary that relies on the Linux syscall interface and nothing else. I believe bsd's libc statically links without problems as well.
Libc++ is set up for static linking out of the box (if you manage to find or guess the many cmake flags).
OSX and Windows insist on libc iirc but they're closed systems anyway so controlling your dependency graph is unavailable.
The problem with musl is its malloc implementation. It is subpar when compared to glibc malloc. And we know that glibc malloc is generally subpar when compared to jemalloc. For large-scale applications with many (concurrent) (small) allocations this will be a big performance problem.
I guess (?) it would be possible to fix this by replacing the musl inline malloc implementation by statically linking against the jemalloc.
Changing malloc for a different one you like more would work fine in musl. In particular because it has a sane bootstrap structure which means the dynamic loader can call normal C functions, it'll be swap out the code and carry on as normal. I'd suggest replacing it in libc itself instead of requiring a separate library though.
