xml_name_eth_diagnostics.xsl file goes through all the xml data files and for each persName generates a record with that person's name. The original block of code grabbed the surname and forename and left any other text, but took them in the order they appeared in the data file, so in the output text file you didn't have those two pieces of information ordered consistently.

It took me a few hours to write some code that gets me acceptable results (i.e. surname followed by the forename (or expanded version of forename if there is an abbr and and expan) and no addName or anything else.

<xsl:template match="persName">
<!-- SLA160803 : original code is first block below - didn't ensure consistent ordering; lower block forces order and includes expan if it exists, otherwise includes text of forename

<xsl:variable name="content"><xsl:apply-templates/></xsl:variable>
<xsl:value-of select="normalize-space($content)"/>

-->

<xsl:variable name="surname" select="string(./surname)" />
<xsl:choose>
<xsl:when test="./forename/choice">
<xsl:variable name="forename" select="string(./forename/choice/expan)" />
<xsl:value-of select="normalize-space(concat($surname, ' ', $forename))" />
</xsl:when>
<xsl:otherwise>
<xsl:variable name="forename" select="string(./forename)" />
<xsl:value-of select="normalize-space(concat($surname, ' ', $forename))" />
</xsl:otherwise>
</xsl:choose>

</xsl:template>

In sorting this out, I discovered that our schema and schematron allow a persName element to contain more than one surname or forename elements, but this processing code breaks if there is more than one surname or forename, so I found and edited the approximately 15 instances, all of which were human error of one kind or another, so there are no legitimate cases of a persName having more than one surname or more than one forename element, so I've left this code assuming max of one surname and forename per persName.