1. Zircon, the kernel, is entirely capabilities based. No users, no groups. Those are higher abstractions built on the capabilities system. This is all around a win for security from executing 3rd party drivers to building a sandboxed multi-user system, not to mention is just generally more flexible and less error prone at the kernel boundaries and internally.
2. The WM is scene based. Applications draw to a scene which the WM composites and renders. This means a single draw list is sent to the GPU for each pass instead of many apps spamming their own updates. Also you can do cool things like have objects from one app cast shadows on another app.
3. The kernel API is not a bloated mess and will not become one. Keeping the number of syscalls on the order of 10s not 100s is a design goal. You can see the commitment to this in the way the project is structured. Which brings up:
4. Testability. The project was designed with testability in mind. Not Enterprise Java mock and verify the world shit. Just good practice separation of responsibility between the different layers and enforcement of a sane unidirectional dependency relationship from lower to higher layers. Good luck testing the Linux kernel.
5. The system will update from a single image rather than relying on N parties to pull new patches into their distro and update and test everything N times before releasing to people. Again layers.
This isn't all new by any means, but it's a pretty practical approach to an OS in 2017. This isn't an "academic microkernel", and also decidedly not *nix.
Enough evangelism. Point is, the project is not solely designed to give the big G more control over a platform. Not saying that is not one goal, but technically this thing checks out.
