Map folder conflicts cause save data loss

[telehops]

My mods and Everest install are up to date

Yes

I have recreated the bug with only Everest OR a minimum number of mods enabled

Yes

Describe the bug

having a mod with the same folder structure as another mod, but different bins within those folders, will overwrite the save data of that other mod. i think this is easiest to explain with an example:

secret santa collab 2024's folder structure looks like this:

- Maps
  - SecretSanta2024
    - 3-Hard
      - a bunch of .bins
    - (pretend i listed the other folders here)

now, take the penumbra standalone that people use:

- Maps
  - SecretSanta2024
    - 3-Hard
      - maya.bin
(no other bins or folders than those listed)

enabling this standalone (with ssc3 disabled, as you would if you were trying to play penumbra without lag) will delete your save data for all of ssc3's hard lobby, except for penumbra.

some more details:

• deletion only happens per-save file, when you load into that save file. it doesn't happen on game launch, or to save files you haven't loaded
• this doesn't delete your save data for the easy or medium lobbies, since those folders don't exist
• if the "3-Hard" folder existed without any .bins inside of it, that also wouldn't delete your save data
• the .bin can be named anything or contain anything, even a blank .txt file renamed to asdfasdf.bin will do the trick (and delete penumbra too this time)
• you can nuke standalone save data too, and you can have any number of folder conflicts in a single package. if you wanted to be malicious, you could create a mod that just contains a ton of folders that conflict with various existing mods, and 0byte dummy .bins in each folder

despite the fact that you can make a save data nuke very easily, which would be catastrophic to anyone not using the infinite backups mod, my strongest motivation for wanting this fixed is actually just the fact that people are constantly deleting their collab save data via bad standalones. the most popular way of making a standalone is to copy the mod and then delete all the unused .bins and assets (and remove unused dependencies). this is the easiest method, but it results in a standalone like the one shown above that clears save data for that collab. in addition, people teach each other this method and are sharing those standalones. it doesn't seem to be widespread information that doing this deletes your collab data. i think it would be great if the deletion didn't happen, instead of fighting to get the word out about bad standalones.

Steps to reproduce

1. backup your save data
2. have some time/deaths on a standalone/collab
3. make a copy of that standalone/collab
4. delete the .bin(s) inside the folders, and replace it/them with a single .bin with a random name
5. disable the original standalone/collab, enable the copy
6. load your save file that had the time/deaths (just need to view the chapter select screen, don't need to actually enter any mods)
7. disable the copy, enable the original standalone/collab
8. save data will be gone for any .bins that were deleted

Expected behavior

i don't think this is technically a bug, just a quirk of how save data is constructed. so this isn't what i would call expected behavior, but here's what i think should happen (the solution of someone who doesn't know how celeste's save data system works, of course, so forgive me if it's not viable for whatever reason):

when loading the altered mod, the AreaStats blocks for .bins that no longer exist in the folder should not be deleted. rather, there should be just be new AreaStats created for any new .bins in that conflicting folder. basically, no deletions, only additions. this would 1. make it so that people stop accidentally deleting their sj/ssc3 data, and 2. prevent someone from making a malicious .zip that deletes your save data for any number of popular mods.

the obvious drawback of this is that your save data could get filled with useless nonexistent maps over time, particularly if you're mapping and your bin/folder names change, but for me personally, this would be extremely worth it for not having to worry about standalones deleting my save data*. for the average person who is just installing, enabling, and disabling mods, i doubt there would be very many cases of nonexistent areas staying in their save data anyway. deletion/no deletion could be a toggle too, but if that becomes the case, then the default setting should be the one that keeps all save data. at the very least, there should be some kind of message shown when loading a save file that warns you that some AreaStats are about to be deleted because you have a mod that contains a folder that disagrees with what's currently in your save data, and recommends that you either disable the mod or back up your save data before continuing.

*i personally can just make my standalones have different paths, and encourage other people to do the same, but there is actually a reason to want conflicting paths instead of separate paths. it links your standalone and collab time for that particular map so that your stats aren't split between 2 versions of the same map. right now this luxury isn't possible without also deleting your save data for the other missing maps. that's less important than preventing save data deletion, of course, but it would be an added player QoL bonus of changing this behavior.

Operating System

Windows 10

Everest Version

5806

Mods required to reproduce

not a required mod to reproduce, but here's what i used for testing:

ssc3sj1krhdnuke.zip

this will wipe your data for ssc3 hard lobby (except for penumbra), strawberry jam (adv, exp, and gm lobbies, except for pumber), and 1000 reverse hyper delayed ultras (i just wanted to test a standalone and this was the first i saw lmao). those three original mods have to be disabled.

Additional context

No response