The actual behavior these contrived steps imitate is using AutoCreateAuthorities and CatalogModuleRelink, using LinkerModule: First Match so that in case of duplicate authorities the linker will choose the first, oldest, lowest authid, and then buying one book by an author before he dies, cataloged with Name, Birthyear-, and then buying another after he dies, cataloged with Name, Birthyear-Deathyear. 1. Set AutoCreateAuthorities, BiblioAddsAuthorities, CatalogModuleRelink, and LinkerModule: First Match 2. Create a personal name authority record with 100 1# $aBrzezinski, Zbigniew,$d1928- (imitating one you imported before 2017) 3. In any existing bib record, add a 700 linked to that authority record, just so it has a linked bib 3. Cataloging, new from Z39.50, search for Brzezinski, Zbigniew as author, import and save any record with the 100 field having his $d as 1928-2017. 4. Since your report of newly created authority records shows Brzezinski, Zbigniew, 1928-2017 when you know you already owned something he wrote, go to Authorities and search for Brzezinski. You need to update your previously imported record (well, the fake of one you created), so Edit the one without a 2017, Replace record via Z39.50, find the 1928-2017 record and import and save it. 5. Search again for Brzezinski. Expected results: Because you created the one that was originally 1928- first, before the one autocreated as 1928-2017 from your imported bib record, and you set First Match as your LinkerModule, you should expect that when you edit the first record in a way that causes the two records to become duplicates, that relinking would link both bib records to the first match. Actual results: Both bib records are linked to the second match, the autocreated one, rather than to the original, looking very much like the bib record without -2017 was updated and both bib records were relinked before the authority record you turned into a match actually was a match. As a result, rather than just being able to delete a now-unused autocreated record, you have to merge it to your newly edited record.
Actually, it's not "before" but just a race condition between the saving and the relinking. With more than just two bibs involved, it's anyone's guess how many will wind up on the first one and how many on the second, probably partly depending on how complex and thus slow to relink the bibs are. I'd expect very different results with ten bibs where the only authority-controlled field is a single 100 versus ten DVD bibs with their typical twenty or thirty authority-controlled fields.
The worst part of this bug is actually the Delete action: we think that "Koha doesn't allow you to delete an authority from search results unless there are no linked bibs" but what's actually the case is that "Koha doesn't allow you to delete an authority from search results unless there are no linked bibs *at the time you loaded the search results*". About once a month, I do something that will trigger this and despite knowing about this bug, I wind up deleting the authority which had zero bibs linked at the time, only to see when the search reloads after I delete that I was in the middle of a race of relinking, and I deleted the authority which actually had two bibs attached by the time I deleted it, which results in deleting the linked fields from the bib records as well. Then I have to figure out which bibs I just ruined (easy enough with an author, mostly, but guessing which two bibs you just deleted a subject heading from can be a bit challenging).
"Fixed" by bug 29522 removing the relink on the "merge" when the authority record is saved: no relink, no race.