I'm not a big fan of doing it like this it means that this isn't the original RCT2 gamestate structure. I'd prefer if you just duplicated the structure and called it S6DataClassic

We modified about every RCT structure: rct_ride_object (and all other object types), rct_ride_entry, rct_ride_entry_vehicle, rct_track_design and countless others. I’m not sure why we would suddenly make an exception for this one. (Although I would be interested in undoing the changes to the aforementioned ones and have a clear split between RCT and OpenRCT2 structures. But only if we are consistent about it.)

Also, how would we read the entities from flag 15 files if this field has to remain at 10000? The code references _s6.sprites in quite a few places.

@duncanspumpkin if you duplicated the struct, how would you be able to have all the import code work with both? There would be no common base class that you could use.

We modified about every RCT structure: rct_ride_object (and all other object types), rct_ride_entry, rct_ride_entry_vehicle, rct_track_design and countless others. I’m not sure why we would suddenly make an exception for this one. (Although I would be interested in undoing the changes to the aforementioned ones and have a clear split between RCT and OpenRCT2 structures. But only if we are consistent about it.)

Also, how would we read the entities from flag 15 files if this field has to remain at 10000? The code references _s6.sprites in quite a few places.

You'll notice we always kept the original structure with the original size under rct2/1 why does this one justify breaking that convention. In an ideal world it should read an s6 into an s6 structure, s4 into an s4 and a classic into a classic. Then that is converted into an openrct2. We can share the underlying sections.

@duncanspumpkin can you show how the code that imports handles both variants of the struct? The only way I can see of it doing it is by adding a template parameter to the import code.