OK, after looking at this, it's sensitive to any re-ordering of XML attributes, and it’s making assumptions about where line breaks will or won’t occur in the XML. It’s just too damn fragile. The database schema is totally screwed, too. It’s not actually doing a proper object-relational mapping on anything, it’s just storing fragments of XML in the database. It has three redundant indices on tables. When it wants to actually display a machine in the UI, it does a bunch of string manipulations on the XML to extract the information it wants. It still hasn’t been updated to deal with imperfect/unemulated features on slot cards. It’s still looking for long-removed attributes on the “driver” element that were replaced by feature flags.

Hell, it’s not even dealing with XML character entities properly. Here’s the code it uses for XML character entities, which it only applies to the text content of the “manufacturer” element:
content.replace("&amp;", "&").replace("&lt;", "<").replace("&gt;", ">").replace("&quot;", "\"").replace("&apos;", "'");

Not only does it assume that only a very small subset of XML character entities will ever be used, it assumes they’ll only ever be used in the “manufacturer” element.

Now I can try to improve it. I can try to port it to use an actual XML parser, and rework the database schema to something kind of like a normalised form. But this will take me ages, and take time I’d rather spend actually improving MAME. Pandering to it by putting the “name” attribute first doesn’t actually solve anything – that will cause it not to see the (almost useless and poorly named) “status” attribute instead.

It really needs a re-write to parse the file as XML rather than some imaginary fixed structure. This is the very definition of technical debt. It’s heavily relying on implementation details of how the XML is/was generated rather than parsing it as XML and working with the schema.