This is the simpler to answer: Think of a game like Tempest: it has extra data (the webs), however such extra data which is not realistic to be user-made. Also think about something like Shadowgate if it was realized: it is a story as-is, no user made content. In these games there is no practical reason to have more than one file as there is no point in handling the data file separately from the game executable.
So this additional game data feature would serve this demand: You can add extra stuff which is not to be burned in the Flash, but rather you will load it later. SPI RAM games could use this more extensively.
There is no point in adding "magic" stuff there when there is plenty of room still available within the 512 byte header. The header can contain such info. However I would only add it once there is any realistic possibility of using it (there is no point in adding information fields if there is nothing which could use them: currently neither bootloader have any realistic possibility of implementing such a feature, nor there is any emulator which would offer a game selector which might).
Then the save states.
First of all, you seem concerned about write safety. I think if the game uses the FS library to write, it doesn't matter what concept it uses, safety is the same. If the game fails to correctly select the area to write into, it will cause big trouble on the card. No matter where it should have been writing (region in UZE file, central save file, individual save file, whatever).
Having a kernel library for such a feature makes things safer as the library itself can be made safe.
Now what are the pros and cons of each?
Generic unregulated own save file(s) for each game
- (+) Only this method allows for true user made content in a convenient manner for the user.
- (-) Since we don't want to add full FS support for its complications, the save files must be there and sized appropriately to work. This negates almost all benefits which this method would offer. If the user omits the file or deletes it, the game becomes inoperable, it is so difficult to clear saves (if you don't have a clear save file, you are busted). So you still can not move the game without saves.
- (-) It would be difficult to make proper kernel support for this.
- (-) It would be difficult to make a generic save state clear function for this.
- (+) It can have proper kernel support (due to the file's standardized structure)
- (+) It can have a generic save state clear function (due to the file's standardized structure)
- (-) Due to the fixed size it has to be large to accommodate demands, although it could be mitigated by standardizing it with an arbitrary capacity which you can set to your needs (the games on the card).
- (-) Moving saves is difficult, particularly if the user had games on two SD cards, he would need some software assistance to merge saves if he wanted to move them onto one card. This can get bad if he occasionally plays on emulator and occasionally on real hardware: even if he plays different games, he can not easily merge saves.
- (+) It can have proper kernel support (due to the area's standardized structure)
- (+) It can have a generic save state clear function (due to the area's standardized structure)
- (+) Moving saves is easier as two games won't interfere with each other. You just move the game and the saves get moved with it.
- (-) The area still has a fixed size, however at least this size belongs to one game and can be set by the game author.
I really don't like the central save file approach. It would work for high-scores as high-scores aren't so much essential for gameplay, but if you started really using the SD, then you could start to have more important data, such as a real save location. The player may really want to be able to move it somewhere else (such as from emulator to real hardware), and the central save file could make this a big mess. So I side with either .UZE file field (less files on the card) or standardized own save file (more files on the card), a generic own save file certainly should be a no-go (without real filesystem functions).
When I mention the UZE file, I say absolutely no to expand it from within the game without any awareness of the filesystem. There should be some new indicators in the UZE header which reserve a region within the file (after the game binary) for the save data, which when empty, is zero. So the area would always exist.