I could, but for us SA is reserved, not actually used by anyone. I'd have to go get the password out of the safe ...
Which happens to be the one I have adopted 
but its one-more-thing-to-remember whenever I restore a database
I think MS's replies are a bit of a cop-out:
There are a number of reasons behing the current behavior:
1) In the general case, we cannot assume that the user who owned the database which was
backed up even exists on the instance that it's being restored to.
2) We need to ensure that the user currently performing the restore has the necessary priveleges
to apply log backups to the newly restored database.
3) We ensure that the user currently doing the restore has full privileges on the database, and can
thus change ownership to whatever is appropriate on the target system. If the database is
read-only, it can briefly be set to R/W for the modification, and then set back.
#1 is true, but a RESTORE AS xxx would allow choosing a new owner (which would be required to exist). Currently I can restore as me then delete my Server Login I expect? Seems to me as broad as it is long on that account: Fail to restore with non-existent UserID from old machine vs. restore with any-old-login which then is inappropriate
#2 could be solved by issuing the "AS xxx" option in combination with the "WITH RECOVERY" command
#3 "briefly" setting a READ_ONLY database to READ_WRITE is probably Gross Misconduct in some places! let alone the consequences of forgetting/failing to re-set it back to READ_ONLY.
OK, I'll stick to ALTER AUTHORIZATION ON DATABASE for now, and I'll stick that in my Restore Script Snippets file 