Exactly. The relatively smooth upgrading of software on Unix-like systems is because you can
unlink the old file and create a new file with the same name. The old one will continue to
exist, with its old data, as long as a process has it open. If you try to fix the suid binary
problem by forcibly removing a file, or overwriting its contents, then you risk breaking
(Since writing bytes to a file is not atomic, you could theoretically introduce new security
holes by overwriting the contents of a suid binary. What if someone runs it halfway through
the update, when it contains a mixture of old and new code?)
One answer would be to move the suid flag out of the inode and put it in the directory entry.
Then you could make as many links to a file as you wanted, but you wouldn't be able to get the
suid magic (unless, of course, you have permission to set the suid bit anyway). But given the
conservatism of Unix-like systems and the large amount of filesystem code that would have to
change, I can't see this happening soon.