Fairly easily.

A relatively small number of syscalls are used as part of implementing other functions. Most if not all of these are made via macros that expand to inline syscalls; by replacing them with a call into your own function that implements the equivalent of the syscalls you need "on the metal" rather than calling into a kernel, most of the work is done.

Some syscalls are made directly from assembly source files because C is unable to represent the work that needs to be done around them (e.g. clone and vfork) or simply because their usage is arch-specific. These obviously use the trap-to-kernel instructions directly and cannot be re-routed as described above. Still the number of files is so small you could just rewrite the asm.

One future direction (albeit with lower priority than further functionality/quality improvements, unless somebody funds it) is making it easier to port to bare-metal and documenting the process.

Some of these things are covered on the comparison page I did at http://www.etalabs.net/compare_libcs.html

In regards to fts.h, the version in glibc is not even usable because it only works in 32-bit off_t mode, and stat() randomly fails in this mode due to modern inode numbers being 64-bit. See the recent thread on the glibc mailing list: https://sourceware.org/ml/libc-alpha/2014-03/msg00408.html and the bug tracker issue linked.

At this point both musl and glibc only cover a very small portion of C11 additions. glibc has a GSoC project proposal (with 3+ students interested in it) to add C11 threads, which is one of the big missing areas. We've been holding off on doing so in musl in an interest of making sure we do it in a way that's ABI-compatible with glibc, so we'll probably add C11 threads in the near future too.

The original idea goes back to around 2005 and frustration at the ever-growing size of glibc and poor (slow) support for UTF-8. At the time I made a prototype and used it personally. In 2010 I relaunched the project with a goal of doing it a lot better and targeting user bases who might actually be looking for a new libc; later on this turned out to include a lot of people unhappy with GPL/LGPL, so we re-licensed from LGPLv2.1+ to MIT.

@dalias is very active on the glibc list. Back when he started it was in a dark period and not responsive to change. It is better now, but there is space for something as different as Musl.

At the time the project was started, Ulrich Drepper was the maintainer of glibc and the official response to any bug report was "STFU". So, no.

Aside from that, while a more permissive license was not part of my original goal or vision for musl, it's something that could never have happened by working on improving glibc. Right now we're facing a situation where Linux has been fragmented into a "GNU/Linux" minority made up of hackers' desktop PCs and enterprise servers, and an overwhelming Android majority. The latter is using a grotesquely incompatible, poorly designed, non-standards-conforming libc called Bionic, and if you want to run existing C programs on Android, you have to add heaps of #ifdef hackery to them to make them compatible with Bionic (much like the #ifdef hackery needed to make C programs work on Windows).

musl can provide a real, standards-conforming libc for use on Android that's still light and MIT-licensed (important because Open Handset Alliance members have a contractual obligation to Google not to add copyleft code to the system they distribute). This means, in theory, we can do away with the whole #ifdef mess and just run existing, portable software on Android. In short, it has the potential to free FOSS projects from getting bogged down in the maintenance burden of supporting yet another gratuitously-incompatible system (Android) in order to remain relevant.

LD_PRELOAD alone wouldn't do it because glibc's dynamic linker is closely tied to glibc. In particular thread-local storage requires close cooperation between them. Likewise, musl needs its own dynamic linker.

What could be done in theory is replacing /lib/ld-linux.so.2 with a symlink to musl. One of the long-term goals for musl is for this to actually work, at least for many programs. But right now there are a lot of glibc-specific symbols that get pulled in magically by glibc's headers, even when the program at the source-level is 100% portable code, and we don't have coverage for all of these.