I believe I have a good solution to the problem. I've been planning it for a while but haven't gotten around to implementing it, but I might as well say how it will work while the topic is hot!
EEPROM management should be the responsibility of the hex uploader. When games are published to hex files, it will be necessary (and very convenient) to have a bit of metadata associated with them. Obvious fields are the game name and author, but one of the more critical fields will be EEPROM usage. The metadata will specify the ranges of EEPROM bytes the uploaded game needs to use.
Here's how the process works: You upload your first-ever packaged game. This game includes the EEPROM metadata. The hex uploader creates an "EEPROM file" on your computer's disk for your Arduboy, recording the fact that you uploaded a game using specific ranges of EEPROM. Those ranges of EEPROM will be labeled "pending" in the EEPROM file. The ranges are also associated with the game ID. Finally, the code uploads and you play the game!
Ok, that was fun! Now you want to play another game. You download another packaged file and plug it into your hex uploader. One of two things can happen at this point:
1) There is an EEPROM usage conflict. As you clicked the upload button, the hex uploader checked if the new game's requested EEPROM ranges overlapped with the "pending" ranges associated with each game that had ranges pending on that Arduboy's EEPROM file. It found one, so now it's quickly uploading a sketch that contains code to back up that section of EEPROM to the computer. After that, the "pending" ranges of EEPROM associated with the older game in the Arduboy profile are cleared. New ranges for this second game are now created, associated with the game, and labeled "pending." Finally, the game code is uploaded to the Arduboy.
2) There is no EEPROM usage conflict. This situation can be handled in many ways, but I would suggest providing a user option for "always backup" (to prevent bad-behaving sketches from wreaking havoc on your save data" or "lazy backup" (so only conflict situations will back up EEPROM to the computer, and the whole uploading process will be faster.)
One of the problems remaining is with the hex uploader identifying different Arduboys, and associating them with their EEPROM file. I propose that we use a few of those reserved bytes at the beginning to store the name of an Arduboy's owner. It would be helpful for serial tools, and could bring up cute situations in developed games! (I really want to be able to say "hi, $OWNERS_NAME!" in games! )
I forgot to say what happens when playing games that have backed up EEPROM! Ok, you just clicked the upload button. Well, if the memory for the game is still labeled "pending," then nothing needs to happen, because the memory hasn't been overwritten. And if the memory has been overwritten, (AKA there is no pending entry for that game's ranges) then it will see if there is a backup of those ranges, upload a sketch with code to restore the EEPROM for those ranges, and finally upload the game.
Anyway, I hope I have shown that this is a good solution. Externally-managed EEPROM will protect you from losing your game data, as well as simplify EEPROM programming for everybody. Not only that, but it can be expanded on: save backups and save sharing will become trivial. And if an SD card version of the Arduboy comes out, it could implement a scheme like this too, allowing as many save files as you want for as many games as you want-- all stored on the SD card!