So far as we know (or at least I am aware) there's no
<AffectsSavedGames>0</AffectsSavedGames> column for civ6 in the modinfo file.
DonQuiche had set IGE to be saved games compatible (ie AffectsSavedGames was set to '0') at least as far back as Dec 2013, which is the earliest version of his mod I have a copy of. Earlier versions than V38 might not have been set this way.
As far as "GoTM" goes, I interpretted that as Game Of Thrones Mod, and couldn't find a Game of Thrones Mark 2 mod for civ6 so was confused. I think you'll find not a large overlap between at least the civ5 mod-making community and the Game of the Month crowd.
EUI worked the way it did in civ5 both because it was packaged (as were MultiPlayer mods) to be added into the game's DLC folder (so the game would think it was a valid expansion and therefore not turn off achievements) and because it was entirely UI without any changes made to the game's database.
The vast majority of all other mods made for civ5 would affect one's saved games because they made changes to the game's database. Which is where the general rule with regard to civ5 modding came from. Changing the list of mods that were enabled when a save was made was in fact possible, but this almost always resulted in an irretrievable corruption of the saved game once this change in the list of active mods was attempted, because civ5 worked on a system where all buildings, units, policies, etc., present within the base game were assigned an ID#, as were all such items added to the game via a mod, and the assignment of these ID#s was done in order the mods loaded once a player hit the "NEXT" button on the civ5 mods menu. Mod loading order was therefore of ultimate importance, and because of the way a mod could be made to be dependant upon or made to load after a different specified mod, and the fact that mods loaded primarily in order they were last enabled, adding new mods to the mix of a game-in-progress nearly always would cause re-assertion of (ie, changes in) the order in which mods loaded into the game, with the result that a World Wonder that was added by a mod could end up with the ID# for a unique version of a Stable that was added into the game by a different mod if you fiddled around with the list of mods active for a game. Updating a mod to a new version would have the same kind of an affect, except that this was even more prone to causing an irretrievable corruption. This is actually what the
<AffectsSavedGames> column in the civ5 modinfo file was meant to prevent.
If you look at the modinfo of my civ5 No Tech Beelining mod you'll see it is not set as
<AffectsSavedGames> precisely because it does not add anything new to the game's database in civ5 games. My other mods for civ5 all pretty much have this column set to '1' for "true" as regards affecting saved games because like greater than 95% of all civ5 mods, they add something to or alter something already in the game's database.
Civ6 does not as yet seem to have the capability of stating that a mod has no affect on saved games, nor allowing you to add a new mod to the list you are using at least so far as the modding community can have confidence as yet on the effects on how the game handles re-creation of the game's database when a mod is added to or removed from the list, so you need to follow the general rules of civ5 modding, even if all you are using is an EUI-like mod that only tries to make the UI more friendly:
- if you sart the game with modX enabled, you must complete the game with modX enabled
- Do not update a mod to a new version until just before you are ready to start a new game
- Do not alter the list of enabled mods you are using for a game-in-progress by adding a new mod to the list unless you are 100% certain the new mod does not actually affect the game's database. The same applies to removing a mod from the list.
- Civ6 Special Rule: Mods that only have a Gameplay lua or fundamentally rely on a Gameplay lua running should not be used unless the Gameplay lua is only for the purposes of creating a set of conditions (whatever they might be) when a new game is started. This is because gameplay lua-scripts are not reloaded like UI-lua files, SQL files and XML files are reloaded along with a saved game.