> I often
> used to extract packages or tar files in /tmp (setup as sticky)
> because of quota or disk space limitations in ~. Having the OS tell
> me 'ECANNOTMAKESYMLINKBECAUSEOFPOSIX' at that stage would have made me
> extremely pissed.

I don't think this is an issue.  No one's going to stop you making
symlinks in subdirectories of /tmp that you own -- remember, they
aren't sticky, only /tmp itself is.  So /tmp/symlink would be
illegal under that particular scenario, but /tmp/lukem/symlink wouldn't
(because /tmp/lukem, being created and owned by you, probably won't
have the sticky bit set on it).

Me, I don't really care too much whether you forbid symlinks in
+t directories, or allow promiscuous removal.  Either solution leaves
you with a more consistent universe.  Symlinks themselves are
a fount of inconsistency, as are +t directories -- because they both
violate the simplicity of the original unix filesystem model.
Put the two together and you've guaranteed yourself a flame war ;-)
Don't get me wrong, I think that both features are very useful.
But I think we pay for the utility with inelegance.

If pressed, I'll say go for the Lite2 model.  Why fight a
question that really has no elegant answer?

-- 
/* ronald@cpm.com.my +60 3 241 5232  |  ronald@demon.net +44 181 371 1000 */