I'm working on a Commodore64 side-scrolling action adventure, in which there's a continuous big world to explore, divided in several maps, let's say about 20 of 50 screens each. There are two categories of objects (enemies, items) found in the world:
1) Placed in the level editor. For example a turret on a wall or a pistol in a weapon closet. For each of these, 1 bit tells whether it still exists, or has been destroyed or collected by the player. I estimate there'll be about 2000 of these in the game total, so it's 2000 bits of storage in the save state.
2) Created during gameplay. For example randomly spawning enemies, and weapons/ammunition dropped by defeated enemies. These can be persisted only until as long as the player is in the same map, as the full position and type information needs to be stored, and are not part of the save state. Dying and restarting from the latest save also counts as a map change, therefore losing these kinds of objects.
To avoid unnecessary disk IO and allow for the player to quickly restart the latest save is always in memory, so the whole persistent game state is stored twice in the C64's limited memory. Using more memory for the save state (to allow persisting the "created-during-gameplay" objects fully from the whole world) is not really feasible.
Now, the question: do you feel it would actually be better and more consistent to never even attempt to persist the created objects for the duration of being in the same map, but rather teach the player that whenever something dropped by an enemy scrolls off the screen, it's gone? I estimate that this will not present a resource problem to the player, as there will always be spawning enemies from which more resources can be collected.