The Linux syscall layer (which is most of WSL1) lives next to, not above the windows syscall layer. But e.g. for all that filesystem access functionality, WSL1 doesn't just have to talk to the NTFS driver and generic FS layer but also to a lot of Win32 system libraries. If it doesn't, things will break. If it does, you have dependencies across layers, syscall conventions and system services. WSL1 didn't work because windows internals are a mess.
Do you think they're misdiagnosing the actual problem that WSL1 had?
If they can impose restrictions on applications, e.g. say to Android devs "you can only use this set of syscalls" and use e.g. seccomp to enforce that on Linux-Android, maybe they can get those applications to work. But if they want people to just take any Linux application and run it, they'll have to implement all kinds of crazy stuff. Take rr for example, they'd have to implement ptrace and perf_event_open and other arcane features that you really, really don't want to reimplement.
Today they're probably thinking that with some bounded amount of work they can run "90% of Linux apps" or something like that. But Microsoft thought the same thing about WSL1 and it didn't pan out, hence WSL2. It's strange to me to see Google failing to learn from that mistake.
Similarly, what is accessible from the NDK is limited: https://developer.android.com/ndk/guides/stable_apis