I am gratified at the extensive knowledge of LCRIs that list participants have exhibited in this discussion, and at the excellence of the discussion. Sometimes, however, we do have to refer to AACR2 itself.
Unfortunately, I cannot tell from Gary's initial message if the headings he cites have been revised to include fuller forms of name and dates, or if they were created that way. If they were created with a $q and $d, they are in accordance with AACR2 Chapter 22.17A (adding dates) and 22.18A (adding fuller forms of name) Both sections have an option to add this information, when known, whether or not there is a conflict. The LCRIs for 22.17 and for 22.18 both state that we exercise these options.
In exercising the options, we mostly see it as a way of filling in initials--for example, "ARD Franks" becomes "Franks, A. R. D. $q (Antonio Ruggiero Diabolo), $d 1976-" One would not usually see this on a heading in which a nickname, or other suitable name element, is used. "Tony Franks" for example, becomes "Franks, Tony, $d 1976-"
We shouldn't confuse this practice with the LCRI22.17--20, which specifically deals with conflicts in the database. An e-mail to the list gives a very good example of this, "Potter, Ted $q (Edward W.)" In this case, there must have been another "Ted Potter" in the database, which justifies adding "Edward" One can discuss whether or not "Edward W" is justified as the qualifier, but I'm willing to assume the best on the part of the cataloger who created "Potter, Ted $q (Edward W.)" After all, if the world were cursed with two entities known as "Tony Franks", both inflicted upon it in 1976, we could easily end up with "Franks, Tony $q (Anthony R.), $d 1976-" and "Franks, Tony $q (Anthony J.), $d 1976"--which, by the way, is a true situation in my family. Frequently, we just don't have a month and day of birth to add to the year as a qualifier, and must use the $q subfield as a qualifier. In fact, in the case of my two cousins, it wouldn't matter if we did know, as they were born on the same date.
Aside from applying the rules themselves, there is a second point to keep in mind about the database itself. It is in flux. Headings are constantly revised or deleted. The conflict with another heading that yesterday required adding an $q and/or $d to a newly created or existing heading may well not exist next week. We don't (usually) go back and revise the surviving heading and so we see in the database, wherever we may look, the echoes of past decisions.
Anthony R.D. Franks
Team Leader, Cooperative Cataloging Team
Library of Congress