On iOS, the code that you've modified runs in an interpreter but code you haven't changed runs the existing fully optimized AOT code that's already in your app.
There are some similarities. The main difference is that Wine is mostly in-process whereas, in this design is mostly out-of-process. I'll add a section on Wine to the "prior art" section of the doc.
The memory model is similar (a flat, linear address space). The OS APIs are quite different. Fuchsia's OS APIs are designed around an object-capability discipline. For example, almost all the syscalls take a zx_handle_t as their first argument, which means they are operations on an object the process has previously been granted access explicitly. In Linux, many OS APIs operate on the "ambient" environment rather than on a specific kernel object.
I'm sorry, but I'm not sure what you mean by "this manifest." The blog post linked above was written by Wayne Piekarski, who is a Developer Advocate for Fuchsia. My role in the project is as a software engineer.
I understand where you're coming from, but that ends up being an inclusion issue in the project. I'm comfortable having my name and bio "out there" on the Internet, but I recognize that's a privilege. Not everyone who contributes to the project will be comfortable doing that.
> Using an example from the doc, if your child process accesses "/dev/class/framebuffer", can you intercept its communications?
Yes. When creating the namespace for the child, the parent can map names to what whatever communication channels it chooses. If the parent wants to interpose on the child's access to "/dev/class/framebuffer", the parent could map that name to a channel that leads back to the parent.
> Can a process create a custom sandbox and run, say, AppMgr with limited permission to limit the permissions of all apps it manages?
Yes. That's useful for testing as well as for sandboxing.