The fact that the you can't get the XML of a type defined by (typCreate) means that there's no way for more than one mod to make changes to the same type without completely overwriting it, even during <OnGlobalTypesInit>. This defeats the purpose of the XML functions. So the XML must be saved at least until the end of <OnGlobalTypesInit>.
I understand that keeping the XML after <OnGlobalTypesInit> would increase memory usage and bloat save files. However, mods with usesXML="true" already require keeping the XML for types that are defined in files in memory, so it probably wouldn't be significantly worse to also keep types defined with (typCreate), especially since they'll often be overrides of existing types. So the main cost is storing the modified XML in the save file. But the advantage is that we'd be able to define new types based on existing types after <OnGlobalTypesInit>. Currently we can only do this if it's based on a type that's defined in a file and wasn't overridden in <OnGlobalTypesInit>, so it's not reliable. The amount of data stored in the save file might be reduced by running the <OnGlobalTypesInit> code during loading, if it isn't already. That would increase load time, but allow the save file to store only the XML for new types, rather than overridden ones. One way or the other, I think it's a price we might be willing to pay, but perhaps only for mods that specifically require it, e.g. usesXML="always" vs. usesXML="onInit".
See also:
https://forums.kronosaur.com/viewtopic.php?f=3&t=6582
https://forums.kronosaur.com/viewtopic.php?f=8&t=7727
Actually, running <OnGlobalTypesInit> again is a terrible idea because it could cause types created after game creation to be modified when loading. (Although, it would be cool to allow mods to do this deliberately with something like an <OnGlobalTypeCreated> event. Ticketed.)
But the XML files for the entire base game are only about 3.5 MB, so it seems like even with a lot of mods creating and redefining types, it wouldn't be prohibitive to keep all of their XML in memory and each save file.
I suggest that the XMLs for typCreate types could also be stored in an external .xml file for testing/accessibility purposes
I'm not 100% sure if I've addressed the root problem, but I've fixed the engine so you can ask for the XML (typGetXML) of a dynamic type. This only works with the usesXML="true" flag.
Note that we've always had to save the XML of dynamic types, but the call to typGetXML was busted for dynamic types.