But what you *do* have is a loader that can interpret individual files (which at least at one point, appeared to contain direct dumps of data structures pertaining to global game state instead of deltas, judging from the sheer number of zero bytes as well as the contents of the non-zero bytes -- I have not bothered to examine recent data, so this might have changed), so you can write a loader which interprets a header specifying the organization of multi-section file (number of sections, type of each section, length) and then chains to the previous loader for each individual section (for a straightforwards approach). Given that much of the game is *not* simultaneous-phase, this would not be a significant departure provided that your software architecture hides the details of the I/O from the data model and logic components.
The slightly tricky bit is to determine which files to package, since each subsequent phasing player needs a slightly different view. One possible approach is to eliminate leading sections that originated from the next phasing player, because there's no sense passing him data that he himself generated (but he does need updates from subsequent play).
For simultaneous play, if you use the obvious N-way distribution instead of sequential you can at least have the loader be set to load all files matching the expected pattern in whatever order you desire, and to balk entirely if the full set has not been received yet -- the player is not likely to want to put these files in different directories or to rename them just to spite you, and if he does, it's his own fault. This should work provided a flag of some kind notifies all players that a given phase will, in fact, be simultaneous rather than sequential.
The obvious elephant in the room is how in a game with hidden information you can have both rules enforcement *and* fog of war, but moving to a dedicated-trusted-host system w/ decent public-key encryption for both tamper-resistance and privacy is not something I'd personally prioritize for a game with this many file exchanges and this low a fan base, especially compared to resolving outstanding major or blocker bugs.
And actually I wouldn't prioritize e-mail within the program itself, or necessarily even the above changes re: packaging files, because there are a large number of (free, even) shared-folder services which let everybody stay in synch in the background and thus minimize user-visible transfer time (at least, if there computers are powered and networked prior to playing EiANW). Thus, there are already available solutions for easing the file transfer. The file loading after these transfers may be slightly obnoxious, but that's merely *obnoxious*, not potentially game-breaking like, say,
http://eiamantis.babel.com.au/view.php?id=639; or rules deviations that would be nice to revert (like being able to add components to political combinations, or conceivably the original rules regarding where you can place minor factors during reinforcement phase -- right now, I can transport a stack of barely-filled minor corps and then reinforce them on arrival without being able to trace supply to the minors themselves, which is somewhat weird and possibly abusive, and significantly weakens the impact of depot limitations).
