- A note that orphaned FSNs and FSLs cannot be easily distinguished from ones referenced by junctions and FSNs, respectively. Therefore objects will tend to pile up. This is a resource consumption consideration. Resource control issues are, IMO, a security consideration.
I don't think this is a significant problem, or a security problem at all. The fact that, once I have allocated my resources for an object, you might decide to stop having any references to it, does not create a security problem for me. This is analogous to my publishing a web page, and then you later deciding not to link to it any more.
I've lacked the time to pay any more than fleeting attention to the NFSv4 work, but not surprisingly, the concepts mentioned here have analogues in AFS. What NFS calls a "fileset" we call a "volume". Volumes have names, and each AFS "cell" (collection of servers and volumes under common administrative control) has a database which maps volume names to locations. What NFS calls a "junction" we call a "mount point", which is a special object in the filesystem which refers to another volume, possibly in another cell.
My observation over the years has been while it is possible to create mount points anywhere in the filesystem, referring to any volume in any cell, it is relatively uncommon to do so. Most sites apply some structure to their filesystem namespace, such that a volume used for a particular purpose will have a fairly predictable name, and be referred to by a "canonical" mount point in a fairly predictable location. Volume and mount point are typically created at the same time by the same administrator (or, more likely, by a set of tools designed to automate this process), and are also removed at the same time when no longer needed. Others may create additional mount points, but this is fairly uncommon and most sites make few or no provision for keeping track of them.
In AFS, cross-cell mount points are even less common; the most common usage involves a single mount point to a canonical volume in each foreign cell (by convention, named "root.cell"), with other cross-cell mount points being extremely rare in most deployments. I suspect actual deployment of NFSv4 will be somewhat different in this respect, but one aspect I would expect to remain similar is that the looser the organizational relationship between the location of a junction and that of its target, the more likely the target will be one of a small number of well-publicized entry points.
The upshot is that this model is unlikely to create the sort of problems you imagine, because in practice there will always be at least one "canonical" junction leading (eventually) to any given fileset. Note that this point also extends to the intermediate objects, but more so; I'd expect management of FSN's and FSL's in practice to be fairly closely tied to management of the filesets themselves.
-- Jeff