More interesting! I had not yet noticed the ExtraInfo class. A few ideas are circulating in my head simultaneously, so I'll try to keep them in separate paragraphs as I write.
One is that we appear to have been taking different approaches in terms of future-proofing. I've been generally making it like Civ3 unless there's a way I see that doing so will box us in. In part that is because it's what I know, in part it's because I suspect that will be a difficult enough task, and in part it's because I don't know what else exactly we would be working towards. We all have pie-in-the-sky ideas (and come up with more ones as we go), so I don't know which ones we'll wind up using eventually.
Another is that the "legacy/Civ3 mode" reminds me of the Windows NT architecture, and how it had several different modes it could present itself as. One was the Windows mode, which is what we all know. Another was a Unix mode, which provided POSIX compatibility and allowed Microsoft to sell NT into markets that required POSIX compatibility. A third was the OS/2 mode, which allowed Windows NT (through 2000) to natively run some OS/2 applications. I believe the same underlying concept us used in the new Windows Subsystem for Linux (WSL). But what it means is that the Windows API is not really the native API of Windows NT. There's a lower-level NT API, which the Windows, Unix, OS/2, and likely WSL layers all use, and which isn't publicly exposed to programmers outside of Microsoft (though some have figured out how to use it). But what made me think of it is the concept of having layers of what's considered core to the engine. File ID and tile index are core to Civ3, but they may not be core to all ways in which C7 presents itself to the user.
It's probably apparent by now that I'm often the rein-in-the-ambition, will-be-happy-if-we-can-match-Civ3 person on the dev team. So I'm a bit torn. If we try to make everything flexible, I'd argue we would be, to use a term a manager of mine once used, gold-plating the project - basically, over-engineering it so it could support possible future extensions that we don't really have any way of knowing whether they will ever exist. Some later peers would use the term YAGNI (You Ain't Gonna Need It) for the same basic concept. IMO, the challenge is knowing what it worth planning ahead for and what isn't, and I tend to lean on the side of past attempts along this line haven't met their ambition, and thus exercising caution.
But
sometimes it is worth architecting a little bit ahead. I remember one time with a real estate project where we asked, do we need to support mixed retail/apartment complexes, and the business partners said no, we're never going to do that. So we didn't built support for that into our database architecture, and of course six months later they wanted mixed apartment/retail complexes. It would have saved us a lot of time and effort to make the database a little more flexible up front. There was another, smaller example on that project where our business partner told us to do something that seemed quite counter-intuitive, but insisted he was sure that's how it should be done. I spend a few extra minutes and made it so that if he reversed his decision, we could reverse the behavior to what we thought was intuitive with one line, with comment above it saying, "if business changes their mind about x, reverse this conditional". Sure enough, nine months later, our business partner asked, "why'd we ever do this like we did?", and our analyst showed him that he'd requested it that way, and I changed it to the new way he wanted it almost instantly with a one-line change. Of course, this was all after the analyst and I had been there quite awhile and knew the business domain and our business partners well enough to be able to read fairly accurately what was likely to change and what was not.
This may be an area where some input from
@WildWeazel may be helpful in determining the appropriate level of planning ahead for potential extensions, both in the terrain case and more generally.
