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.
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.
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.
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.
* The team are very helpful, and fix things fast and correctly. You can see some of the detail in this post on race conditions in glibc http://ewontfix.com/16/
* It is very standards compliant, so it is a good portability test for your code. It is a bit like using a BSD libc, except it does have Linux specific syscalls etc.
* Static linking works, which it doesnt properly in glibc. If you want to be like those trendy Go people and provide simple statically linked single file binaries, for running in containers etc then you can. And they will be small: the glibc shared library is 1.8MB (not including rt, pthread etc), while a Musl statically linked copy of Lua for example is only 160k. Static linking is very useful for all sorts of things, my most recent use was cross compiling bianries to run under qemu-user for testing.
* It is BSD licensed so you can use it in completely different projects however you want, eg OSv uses it http://osv.io/
* The code is small and readable. If you want to know how things work you can just take a look, quickly find the code and understand it. Just finding the code in glibc takes ages. I keep a reference copy just for this purpose.
You can use the "cross compiler" musl-gcc that ships with it to build if your code is happy being cross compiled (should be, most things just work). If you have a lot of dependencies it might be easier to use a distro, I use Sabotage in a chroot usually https://github.com/sabotage-linux/sabotage
Also, without the work of the entire community testing and reporting issues getting various packages to work with musl, it would have taken forever to get this far. Testers and bug reporters are seriously under-appreciated!
A few big names are in the process of adding musl-based variants or switching entirely to musl, but most of these are still experimental. Alpine hopes to finish switching over sometime this year. Aboriginal Linux too. Bedrock Linux is already using musl in their latest release, but due to the way their distro works, they're in the unique situation where they don't have to build a lot of packages against the system libc, so they have it much easier.
BTW, one difficulty in libc is that it's hard to know what optimizations are "premature" because you can't envision everybody's usage cases without an enormous volume of experience with third-party code.
