I once had a friend who, due to some ancestral tradition of retaining multiple clans in names, had a name which consisted of six parts. A first and last name with four middle names in between is not quite an accurate breakdown given the tradition (which, as I understand it, is more akin to the Spanish "uno y dos" surnames), but seemed like a close enough representation that ought to be possible in many systems. Of course, it actually was not possible in many systems, and of all the bizarre handlings of his name perhaps the strangest was the motor vehicle division, which decided to use the first three parts as first name, the second three parts as last name, and then apparently some automated system later on helpfully removed the spaces and apostrophe and truncated after so many characters. The resulting driver's license was both comical and nearly illegible.

This case was fairly innocent in that it was seldom even annoying. However, even more common seems to be transgender individuals who have completed a legal name change but cannot get the name field updated in automated systems, a case that can cause a great deal of offense. It seems that the underlying cause here is less format assumptions, though, and more immutability, which I worry the article doesn't quite hit hard enough. I once had my name simply misspelled in, of all things, a university ERP, and it took over a year of nagging to get it corrected. I got the impression that a consultant had to be brought in to make the change. Years later I worked in the kind of corporation that had a lot of "for life" employees, and it was frustrating how often people's usernames no longer matched their names because they had gotten married and been told their username simply could not be changed. Building any system which is e.g. keyed on a name field is absolutely going to cause frustration and expense down the line when someone does something odd like get married. Unfortunately, many software systems make an implicit assumption of immutability by using username as a key for integration purposes, so it cannot readily be changed. MS AD in theory tackles this problem by internally using a GUID to identify users but this is far from complete and username is still critical in some places (mostly third-party integrations), most Linux environments haven't even tried to address the problem.

Finally, the article's section about evaluating whether or not there's a real need for a legal name field reminds me of Heath Fogg Davis's concept of a "gender audit," which is similar and helps to address similar situations. Essentially, he calls for organizations to systematically review every case in which a person's gender is recorded and determine whether or not it is really required. In many cases there's actually no underlying reason (other than someone's thinking that gender was a key and immutable component of identity), and the gender field can simply be removed, preventing a lot of down-the-line frustration in handling cases like transgender individuals. In other cases there is a purpose but it's one that requires no particular constancy (e.g. selection of pronouns in notifications) and so it's better to both make the property readily changeable and, even better, stick directly to the purpose for which you need the information and nothing more--for example, instead of asking for gender, ask the user which pronouns to use.