This seems to be very hot, dizzyingly close to the jackpot. Two tightly related questions:
1) The idea here is that nesters are strictly OS facilities, is it? There's no expectation that a nester can be user code—that a user can write his or her own nester application and run it as he/she would any other executable binary, or is there?
2) There's no expectation that nesters can "intercept" messages to fictitious children, or is there? By fictitious children I mean child nesters or applications that don't actually exist in the VM system's tree of VMs, and instead are just "made up" by the nester. But in truth anything that can send and receive messages is just as much a real process as any other. Think recursively-nested dynamic HTTP servers, or a Unix mount(1) that mounts (arbitrary)* processes instead of files. Or having a conversation with someone else's imaginary friend ... and then with their imaginary friend's imaginary friend. ;)
In the spirit of Plan 9ish userspace mount, some nesters do have to be fast, but not everything has to be fast to be a nester. And not everything has to be reliable or trustworthy to be a nester, either. Also, nesters should have direct access to the state of all their descendants—grandchildren and so on—at least as a matter of principle. Note that a nester which exposes "fictitious" children automatically has such access to the state of those children's descendants.
* A file being a special case of a process. (And distinguishing files from file bodies, the immutable/abstract values that may be the state of some given file at some time.)