For my two cents worth.
I really think we should just partition the EEPROM into say, 8 blocks of 'save area' and have a header area that has a single byte indicating if a save area is 'full' or 'empty'.
Each game then can check a single byte to find if there is a save slot available. If there is not, it is up to that game to play nice and inform the user or blast someone elses save slot.
Each slot can have a couple bytes at the start used to store some sort of id, eg, enough for say, 12 ASCII characters. the rest is for you to use for storage.
The benefit of this is we can have a single sketch that can be used to manage saved games (eg, present them as a list, back them up, delete them, etc). This sketch is analogous to the 'explorer' or 'finder' on Windows/Mac etc.
The second benefit of this is the power of constraints. If you cannot fit your save game in a save slot, you either need to redesign it, or split your save file over two slots and deal with that.
From reading the other discussion, there seemed to be a lot of talk about trying to give each game exactly what they require, and then manage that. I believe it makes more sense to treat the EEPROM as a file system with 8 blocks of a certain size, instead of a contiguous block where you try to fit yourself in.
Of course, I am not an Arduino heavyweight, and I have not programmed games before where this has been a problem. I am just approaching this from the POV of things like the early memory cards on things like the PS1, where you could very quickly fill it up with save files and would have to clear some out if you wanted to save your game.
Also, this method avoids any annoying issues with fragmentation, overwriting, etc.