In them, we explain that the GUID generation routines have an internal cache that prevents duplicate GUIDs from being generated. In IFC, these functions are called once per element, and then a call to the ExporterIFCUtils.EndExportInternal method clears this cache for the next IFC export. Please note that the first time you call these routines, they have consistent values from previous sessions.

For now, there are two workarounds:

Only call the functions once per session, and store their values.

Call ExporterIFCUtils.EndExportInternal to reset the internal cache.

To recapitulate, the IFC GUID is based on the Revit UniqueId.
If the UniqueId is changing, then so will the IFC GUID.

I suspect that when you save a file, you change the EpisodeId of the document.
The unique id of an element is based on the EpisodeId and the ElementId.
If the EpisodeId is reset on an undo of a delete, that would explain it.

For the issue of consistent GUIDs, Revit ensures that:

No two GUIDs in the IFC file are ever the same. This is a 100% guarantee.

For all IFC entities that are created from Revit elements, we create a consistent GUID (it doesn't change between exports). Note that that is based on the UniqueId being consistent, so if there is an issue there, then that will clearly affect IFC export.

For other entities, on a case-by-case basis, we can make some of them have consistent GUIDs. For many, though, it isn't possible (or extremely difficult).

I looked at your sample files and note a couple of cases that could be improved.
In general, though, most of the GUIDs are consistent and unique as per rules 1 and 2.
We will improve this over time to reduce the noise in 3, but it is very difficult to remove all of the noise without a lot of extra storage in the Revit file.