We'll probably have to implement some additional consistency check or additional marker that ensures we're really loading a compatible game, and not one that by chance uses the same SL version.

SpringPP uses a different chunk header format for RIFF chunks, so attempting to load it in trunk will fail with a corrupt savegame error quite early.
For what it's worth I've already implemented heuristics for detecting overlapping/soon to be overlapping SpringPP and ChillPP versions in my branch.

I don't think this is worth worrying about, the patchpack savegames will simply fail to load.

The exact patchpack savegame versions are as follows (as of JGRPP 0.34.2):

enum SaveLoadVersion : uint16 {
	...
	SLV_ENDING_YEAR,                        ///< 218  PR#7747 v1.10 Configurable ending year.

	SL_MAX_VERSION,                         ///< 219  Highest possible saveload version

	SL_SPRING_2013_v2_0_102 = 220,
	SL_SPRING_2013_v2_1_108 = 221,
	SL_SPRING_2013_v2_1_147 = 222,
	SL_SPRING_2013_v2_3_XXX = 223,
	SL_SPRING_2013_v2_3_b3 = 224,
	SL_SPRING_2013_v2_3_b4 = 225,
	SL_SPRING_2013_v2_3_b5 = 226,
	SL_SPRING_2013_v2_4 = 227,
	SL_TRACE_RESTRICT_2000 = 2000,
	SL_TRACE_RESTRICT_2001 = 2001,
	SL_TRACE_RESTRICT_2002 = 2002,
	SL_JOKER_1_19 = 278,
	SL_JOKER_1_20 = 279,
	SL_JOKER_1_21 = 280,
	SL_JOKER_1_22 = 281,
	SL_JOKER_1_23 = 282,
	SL_JOKER_1_24 = 283,
	SL_JOKER_1_25 = 284,
	SL_JOKER_1_26 = 285,
	SL_JOKER_1_27 = 286,
	SL_CHILLPP_201 = 201,
	SL_CHILLPP_232 = 232,
	SL_CHILLPP_233 = 233,
};

I agree with Eddi - the fact that some patchpacks used a version only slightly ahead of master isn't our problem, and the games will just fail to load as expected.

It may become a bit of a problem if people start reporting these saves. It would be nice to at least have a way to easily tell whether it's a patchpack game or not.

For legacy, I know of at least 2 Spring 2013 savegame formats that are already in trouble: 191 and 201. With asserts enabled, they simply crash the game. Without some reword like JGRPP, very little we can do about that now :)

Newer versions seemed to me like very low effort to solve, so I created #8411.

Have you tried a similar approach for the following save game versions (with a more friendly error message)?

• Savegame versions 2000, 2001, and 2002 (tracerestrict branch)
• Savegame versions >= 32768 (JGRPP)

We are far far far far far FAR away from hitting 2000, so no, there is currently no code for that :) I did consider it, but I also found no sane way to add this :)
When we reach 2000, we just add a similar blob ... but I strongly doubt that will ever happen :) (~250 versions in 15 years ... :P)

There are pretty much 0 savegames in the wild which user versions 2000 - 2002.