>> In that case, the sticky-bit suggestion ought to satisfy your desire
>> for a way to mark them.
> They're already per-symlink -- if you don't want them, don't use the
> magic sequence.

That requires changing everything that creates symlinks to bodge up the
link-to string to use whatever the escape mechanism is if it happens to
contain an @.  While this might be acceptable if there were some
overwhelming benefit, I prefer to put the onus on the programs that
want the special - magic-link - case, which means marking links that
are to have interpreted magic.  It would also break filesystems which
happen to already have link-to strings containing @.

Symlinks already have six mode bits which mean nothing (07222).  While
I can think of reasonable semantics for all six of them, I don't think
anything is likely to use the sticky bit in the foreseeable future,
making it a very low-cost way of doing that marking.  (Actually, I
don't think anything is likely to use any of them anytime soon, but the
sticky bit seems to me about the least likely to get used.)

You obviously see a downside to doing that.  I must confess I'm missing
it; interpreting magic only when the sticky bit and some kind of
coarser switch (sysctl, mount option, whatever) is set strikes me as an
all-around win: the magic semantics are available when desired, they
don't get in the way when not desired, links created naïvely get
traditional semantics, historical filesystems (whose links
approximately never bear sticky bits) work the historical way....

But you're smart, and know the system at least as well as I, so I infer
I must be missing something.  What?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B