In a mutable hierarchy or tree I see a pattern that I very much dislike.
<a href=http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-adoptNode>Here</a> we see a function, <tt>adoptNode</tt>, 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.
<p>Capsicum recognizes and describes a related design problem <a href=http://www.engr.mun.ca/~anderson/publications/2010/ASA-capsicum-dot-dots.pdf>here</a> with the kernel call <a href=http://www.cl.cam.ac.uk/cgi-bin/manpage?2+renameat><tt>renameat</tt></a>.
<p>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.
<p>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.