Yes, this change fixes a bug that exists in the current nightly build.  The issue is, if you enter a chord and move on, then return later to edit it, what should initially show up as text when you double click the chord?  The code for chord edit mode populates the initial text with the first item on the "names" list.  However, the code that constructs the chord list always loads "chords.xml" before it loads the specific chord description file (stdchords, cchords_muse, etc) you have chosen, so using "append" means that the name from chords.xml always "wins". Thus, even if you were using a chord description file like cchords_muse that uses "ma7" for major seventh chords, if you then double clicked a major seventh chord to edit it, the text would show as "Maj7".  This was something we discussed in the video conference and the consensus was, editing a chord should give you text that most closely resembles how the chord is actually rendered.  Not necessarily the text you originally entered, and *definitely* not some completely unrelated text from chords.xml.

The way I am now constructing this list, the *first* name field in the *last* XML file loaded will win.  That way, a chord id can have as many name fields in chords.xml and as many name fields in the chord description file as you like, but the first one to appear in the chord description file will "win" when it comes to populating the initial text on edit.  If you check the history, you'll see my first cut at fixing this always inserted at the beginning of the list, which at least ensures that *something* from the chord description will win.  But it actually results in the *last* name field in that file winning, whereas I think most people would expect it to be the *first*.