The following are future development ideas mostly outside the scope of developing musl itself, but closely relevant to use of musl as a replacement for glibc or uClibc.
glibc has a feature, _FORTIFY_SOURCE, which hardens programs against many common
security errors using a mix of special bounds-checking functions in libc and
macros and inline functions in the libc headers which use GCC features to track
known object sizes and provide information to the functions in libc.
Rather than developing and maintaining a corresponding feature in musl, we would
like to see a libc-agnostic _FORTIFY_SOURCE implementation built purely on GCC
features. It would be based on an alternate set of headers which use GCC's
#include_next feature to get the libc headers, then proceed to define macros
similar in spirit to glibc's, but using 100% inline functions rather than
support code in libc. This would eliminate all maintenance complexity of
coordinating with musl development and would allow them to be used with other
libcs (even on non-Linux systems) without modification.
At some point it may also be desirable to provide the __*_chk interfaces glibc
has, but this should be purely for the sake of supporting binaryware libraries
or applications, not for linking new applications against musl.
The inability to use mDNS (a multicast-DNS-based zero config system) with musl has been raised as an issue by users in the past. On glibc, using mDNS is accomplished with NSS; obviously musl does not have (or want) NSS.
In principle, however, musl is fully extensible to use alternate hostname database backends in place of normal DNS. All that's needed is a daemon that runs on localhost, speaks DNS, and translates the requests to whatever backend is needed. However it's unclear whether there are any existing tools of this form. Developing one, adapting an existing DNS proxy program, or documenting how to setup an existing program that's already capable could be a nice future project.
There is interest in having musl scale well to NUMA clusters; however the requirements are not well understood and it is not clear how compatible they would be with existing goals and requirements. In particular, having malloc work well on NUMA is difficult and probably conflicts with minimum-fragmentation goals. Some pthreads bookkeeping may be suboptimal, but whether the suboptimality even matters depends on kernel behavior that is not well-understood.