You can use other allocators with musl. For example in Chimera Linux, musl uses the llvm scudo allocator instead of the default allocator packaged with musl libc.

Yes and that's good, but it should be even easier. Rather than every libc needing to invent how to make the allocator pluggable, we should have that separation of concerns stock and shared by all implementations.

the above is incorrect, chimera does use scudo but it patches musl to achieve that

and scudo is probably one of the few allocators that would work for this purpose, it absolutely cannot be applied to any allocator; there are some concerns that get in the way of that, e.g. the handling of ELF TLS in a libc (ELF TLS may not be and in musl's case is not available within the dynamic linker, which means you cannot use __thread and the likes anywhere within libc.so; scudo is designed to be flexible so you can get around it (we shove a pointer to the thread-local state directly in the pthread structure and manually mmap the data for it) but that is not necessarily the case with many other allocators, including mimalloc, hardened_malloc, and others)

The question that popped into my mind is rather: why does Rust rely on the C stdlib at all (e.g. why even call into musl or glibc). Shouldn't the Rust stdlib implement its own allocator which directly requests memory from Linux via syscalls?

That is what Go does. BSDs hate it. https://github.com/redox-os/relibc could be repurposed for this easily enough.