In a mutable hierarchy or tree I see a pattern that I very much dislike. Here we see a function, adoptNode, presumably available to JavaScript programs that requires a caller to present his access to a ‘node’ wherewith that node will be removed from its original parent and placed in a new parent. Here a ‘parent’ is the higher node in the sense of a hierarchy.

Capsicum recognizes and describes a related design problem here with the kernel call renameat.

This is a bad pattern for it mutates the original parent without requiring any token of authority to that parent. If I have exclusive write access to a parent and send you access to some child thereof, I should not have to defend against removal of my access the child via the parent. If I should choose to let you to remove it from the original parent I can pass a closure doing just that.

Some systems try to assure (and perhaps succeed in assuring) that each of some class of objects occurs exactly once in some particular hierarchy. Mac OS X tries to make files always have a unique path name. This is an easy rule to understand but I am not sure of what other benefits it has. Keykos benefitted, I think, of having objects that appeared in zero or more of its directories—directories were by no means primitive in KEYKOS.