Think of it as a database. A table of events with foreign key references to a table of people. Now if someone's name changes, you only need to update a single entry, eliminating both redundancy and inconsistency in our database. If I look up events about Beyoncé Giselle Knowles-Carter, I sure hope that I find things like when she was born! If you insist on tying events to name at the time of the event, you have a much greater propensity for losing information whenever anyone changes their name for any reason! Therefore, from a data integrity standpoint, I think every database engineer would prefer the one name for all history approach. You could even store the name change event itself!
That's one possible schema, which assumes the name is the primary key. Now that we've established that the name can change, I think it makes a bad choice for a primary key. Instead, I would think you look up a name, and get a link to the primary record, allowing multiple names in use (whether active currently or not). I personally think any schema that requires going back and changing primary keys on a record (and thus anything that links to that record by it's key) because of an action that record takes if poorly designed, and likely to have errors, which I think sums up my thoughts on this nicely.
I never said anything about using names as a primary key. Of course, you could expand the schema to handle aliases, but in the end, people have names that they prefer. You are kbenson, and if you were able to change your username, the proper action is to change the username on all of your comments.
Wikipedia uses something similar to what I described under the covers. There's a unique id assigned to a page, but it's ALSO accessible by a title. Internally, the page id is used to refer the page from other items, not the title[1]. This is sort of equivalent to having one or more names associated with your SSN, if you are in the US. Which makes sense, because names are not unique.
