The latter. The state is not kept in sync, and fundamentally cannot be, and because waits are vectored this cascades. Believe me, I tried, if there was a way to pull it off we wouldn't need the kernel support in the first place, because we could just do in-process waits using futex or something, until we ran into a handle that had been shared cross-process.
Ok, in that case I don't really see the point of introducing each inproc object one after another, it's all dead code anyway so better do it at once.
I still think that changes could be reordered to avoid too much of it and get things in place and called earlier: the linux device object could be introduced first, then retrieved and cached from the clients, and then inproc objects could be added at once, retrieved, and then used?