I think the general issue here is that of having semantical (or semantically generated) identifiers. Intuitively, we often assume that the UUID of a person is

I think the general issue here is that of having semantical (or semantically generated) identifiers. Intuitively, we often assume that the UUID of a person is his name (for some definition of name). Then when this changes all hell breaks loose because we are mutating an ID that has been shared to 3rd parties. Some countries don't have a UUID for its citizens. Some countries don't even have a register of its citizens. Even those countries that have a register AND a UUID for each citizen still often make the mistake of making it derived from the "name" (thinking for example of the Italian "Codice Fiscale"), which can obviously cause confusion if you then attempt to change your name. This is very common in a lot of IT systems even when its not names. It's windowIds VS windowNames, it's username VS userId, email VS userId, primaryKey vs ID field etc. The hill I'll die on is the preaching of never ever ever ever using a semantical id. Sure, they are handy (humans can reason better about those than about random strings), but DON'T MAKE THEM THE ID. A handy test to avoid this pitfall is: if tomorrow every value that represent some id-like property (i.e. foreign keys in a db) in my system (string or numeric) was replaced by a unique 1-to-1 mapping to another set of random strings, would my system still make sense? A good ID-based system would survive this. One where there are assumptions like ID = name ++ email not so much (because name <-> aaa, email <-> bbb but name ++ email <-> ccc, violating the assumption)