I’m recently digged into saving system a bit (thanks to @AVS) so hopefully able to answer that.
Though there is developers who can actually explain it a lot better than me.
Unfortunately this is not that easy because current saving system based on serialization. There is no complicated system that read/verify save data and restore game state step by step like some games do. Instead VCMI “copy” game state from memory into file almost “AS IS” and structure of this data is set by the source code itself.
So basically if certain part of source code that affect “save format” changes it’s almost always change entirely. It’s mean even if VCMI will be saving serialized internal structures into JSON and not just binary format that won’t make save compatibility any easier.
Some compatibility for very small changes is possible, but for huge changes it’s will be too hard to maintain. Though it’s technically possible as long as changes are well documented and there will be programmer who can design and create some easier process for support compatibility.
I think that savegame compatibility is thing that not really needed.
User can finish game before upgrading to next vcmi version.
Because there is modding and extending of engine possibilities.
The only question goes to RMG maps (they can be saved only as savegames now to distribute them). In WOG they were written in HMM3 map format to some folder.
So vcmi map format is needed (it’s together with map editor developed) to store random maps to let them be modified or shared.
Does this mean that even when the version is the same, vcmi safegames are incompatible between different platforms/architectures because of differences in integer size, struct alignment and endianness?
No. All serialized structures use boost integer types, which guarantees cross-platform compatibility. Endianess issues were resolved long time ago, and struct aligment is the responsibility of compiler I believe.