It's always mind-boggling to me that software engineers find ways to screw things up, and then hype up effectively bringing back features that would have existed if they had done nothing at all.
Forcing apps into an abstraction layer from the kernel is good design, preventing kernel quirks from being permanent features. Not using GNU is another design choice which can be debated, but it's completely valid, there's no requirement (moral or otherwise) to use the GNU userland with the Linux kernel. Most embedded devices also eschew the GNU userland by instead using Busybox.
That is nonsense.
I could easily be completely wrong though.
But, they also give app authors the NDK. How do you think Android knows whether it's libc or your app making a syscall from native code?
It doesn't - you're allowed access to full Linux-land. The syscall numbers and userland EABI for Android are the same as for any other Linux. They use a different `libc` from most GNU/Linux (one of a few places this wonderful turn of phrase actually makes sense) flavors, but this is no different from Alpine Linux using `musl` instead of `glibc` for example.
As such, you can use `musl`, `glibc`, or non-libc based environments (Rust, Zig) on Android without issue. You can run any C you want, either by porting it to `bionic` (most termux apps, although they support glibc now), statically linking your own runtime (Rust, Zig, etc.), or abusing the dynamic linker into making glibc work (termux-glibc, I think).
Yes, but there are strict SELinux policies forbidding you from accessing certain "dangerous" stuff like execve(), which may end up killing native terminal emulators like Termux (despite Android not forbidding dynamic code execution elsewhere, Play Store policies aside).
Hey, but at least you can remove the tub whenever you want now.