On 1, the libc we're working on[1] is based on musl. It won't ever be 100% compatible with all code, because that runs into constraints imposed by our security goals, but the vast majority of code should eventually just compile when targeting this. (Eventually, because this is all early days.)
On 2, yes, that is explicitly the goals. I'd add that it's not just about OSes, but also about platforms and hardware form factors.
Honestly, that ought to be a non-goal. We already know that POSIX often enforces models that we don't want--filesystem permissions and the fork model are two good examples of things that are broken. So why start with "implement POSIX"?
Also, goading legacy maintainers to adopt the newer, safer paradigms is likely more effective if you show them the traction the new platform is gaining
1. Backwards compatibility with existing libc. (Maybe pick musl)
2. Platform agnostic wasm generation: the same wasm file should run in the browser (with emscripten polyfills) and across ALL OS-es, mobile included. List: iOS, Android, Mac, Linux, Windows, FreeBSD
#1 shall enable decades of legacy programs to work with minimal porting, while #2 shall enable true cross platform capabilities without multiple codebases. Specifically, don't repeat what node did: digress from browser js semantics, instead of polyfilling them