Given what I just read about IncludeOS (I'm not really familiar), it feels like implementing as much of musl as possible is probably the best you can do compatibility wise. There are going to be a lot of Linux features simply incompatible with includeOS, so claiming that 400 syscalls will be implemented is unlikely.
That said - why do you have to get musl compatibility by implementing the Linux syscalls? Is contributing to musl an option?
Your assumption is correct. IncludeOS will never be fully compatible with Linux. Our goal is to provide "just enough POSIX" so that the applications that are relevant for the OS will compile and run. Mostly we're concerned with various "gateway-like" applications - firewalls, load balancers and down the line also IoT-gateways.
Wrt. to why we have to implement Linux-like syscalls; Musl is written specifically for Linux so in order to "unlock" the relevant POSIX-bits that Musl can provide we have to provide the underpinnings that Musl requires.
I'm hoping we can upstream some of our non-intrusive changes to Musl. However since Musl has a very specific purpose (a Linux-specific C and POSIX library) I'm not certain that our changes are within the scope of the project. To date we've only concerned ourselves with a small subset of Musl and only on amd64.
That said - why do you have to get musl compatibility by implementing the Linux syscalls? Is contributing to musl an option?