Roger, I agree with nearly all you have said but when I said before that natural keys could be unique but mutable you said you "vehemently" disagreed with me! Perhaps we are now in vehement agreement.
The one part of your reply I would disagree with is your suggestion that a primary key should be treated differently because of the need to keep foreign keys small. Not every primary key is referenced by a foreign key and not every foreign key references a primary key, so I believe the best answer is "it depends". As for keeping indexes small, you apparently agree that the natural key should be indexed anyway so creating another index on another column is not going to make it smaller. Perhaps you are thinking of clustered indexes but the choice of clustered index is another thing that needs to be determined on a case by case basis. It's unwise to assume that a primary key should always be clustered.
The point of using a surrogate key is so that it's never updated
For sure surrogate keys are usually intended to be stable but it's not the end of the world if you do update them. I've done that a few times and I know I'm not the only one.
CORRECTION: I first typed immutable in the opening sentence when I meant mutable! Sorry about that.
Ok, I think I see three points where we do, in fact, vehemently disagree. The first is in treating primary keys as special. They are indeed special, they are indeed (supposed to be) the only keys used as foreign keys in other tables by design. Thus, mechanically, they need to be as small as possible for space and performance reasons.
Second, the point of surrogate keys is they are immutable. That is the point of them. There is no point in updating them because by design they never change. In fact if you use identities for PKs it's pretty hard to update them--and pretty pointless. If they do change they are not surrogate keys, they are data. And data makes bad primary (and thus foreign) keys. In fact, data makes poor keys in general, the only use for them is in fact to insure their uniqueness.
And third, no, I'm not thinking of clustered keys. 🙂 Primary keys are used in every foreign key index pointing to it. Alternate keys are only generated in the primary table, not the ones who have a foreign key to the primary table.
That means you can burn a lot more room on all the foreign key indexes than you would a single alternate key index.