My ‘natural’ keys are often composite keys, not strings. Like a foreign link is a primary key for example, combined with a removed_at field for a composite primary key. In almost all cases the removed_at field is combined with 1 or more other fields to make a composite primary key.
I’ve been bitten by this before. You might argue that it’s because the domain was poorly designed or natural keys poorly chosen, but in my experience a well-designed schema takes into account that business logic may change, including assumptions about uniqueness forming natural keys.
Much easier to slap a uuid primary key on everything, and unique indexes that are trivial to roll back without migrating all foreign key references, on what you suspect would make a good natural key.
One example that comes to mind is a JIRA-style project_id + database_driven_project_auto_incrementing_int natural key for issues within a project. Bulk migrating issues between projects becomes tricky to do correctly, transactionally, in the database.