Family Historian User Group

I understood that rule from the start... I was not complaining in the least.

I was actually stating that GEDCOM specifically states in its v5.5.1 specification.

The xref_ID is formed by any arbitrary combination of characters from the pointer_char set.
The first character must be an alpha or a digit. The xref_ID is not retained in the receiving
system, and it may therefore be formed from any convenient combination of identifiers from the
sending system. No meaning is attributed by the receiver to any part of the xref_ID, other than its
unique association with the associated record.

So as I indicated, I expected the XREF to change when imported into FH, and this is why it can't be relied upon as an external identifier when transferring a GEDCOM from one application to another!

AND... It should also not matter what the XREF is set to in the database. It is just a pointer for internal use and nothing more.

I actually use the REFN tag to set a secure identifier!

Sorry. I misunderstood your statement. It said that FH does change the XREF, without any caveats.
It might have been better to quote the rules that FH uses, which in most cases means it does not change the XREF.

Sorry, It was me writing too quickly with my one finger on my iPad and not writing more neutrally. I don’t use a keyboard very often unless I’m coding, so typing is slow!

I said, “ FH does change the XREF when it imports a GEDCOM!”
I should have said, “ FH can change the XREF when it imports a GEDCOM!”