"In a previous message, Kenneth Stailey wrote:"
> 
> >> If symlinks were owned by their creators, then this problem goes
> >> away.
> 
> >True.  But it would also require symlinks to have somewhere to remember
> >who created them.
> 
> Is there any reason that the special directory entry could not retain
> the uid & gid for this special case of inode data?

Yes.  If I own the directory, I can then create symlinks and edit my
directory file to give the link away to anyone I want to.  You don't want
me doing that.  ;-)

We have problems with the sticky directories like /tmp and hard links as
well, of course.  Looking quickly at an AIX system here (yeah, I know :)
the symlinks are owned by the creator.  (BTW, v3.2.5)

I vote that the are owned by the creator.

Because this makes me queasy:
mwilley.sc.intel.com $ cd /tmp
mwilley.sc.intel.com $ ln -s /bin/sh .
mwilley.sc.intel.com $ ll
total 21
-rw-r--r--  1 mwilley  wheel  19855 Jul 27 12:19 fvwmrc01843
drwxr-xr-x  3 root     wheel    512 Jul 27 01:16 screens/
lrwxrwxrwt  1 root     wheel      7 Jul 27 14:27 sh@ -> /bin/sh
mwilley.sc.intel.com $ rm sh
rm: sh: Operation not permitted
mwilley.sc.intel.com $ 

It looks like the symlinks really are stored in inodes now, so no FS
incompatabilities would be introduced by ignoring POSIX in this case.

Perhaps a new kernel option?  May I suggest "POSIX_SYMLINKS"?

Mark