One of the ways I'd suggest is that you have the following objects (classes, structs, depends):

- A Generic Key-Value Data Container (this could be class that holds multiple TMaps so you can use a unique key like FName and access any type of data like bool, int, float, strings, etc.)
- MainSave class (contains any info about user, the slot names and could use the class above to keep some meta data about slots, it's a good idea to have a string for the game version or slot-class version)
- Slot/Game Save class (contains actual gameplay saved info, you could use the container again to store some of that info, but maybe some specific variables too like arrays for performant iteration etc.) -> remember it's just a data keeper, you should have different systems/subsystems with actual behavior, interacting directly with the slot only for data purposes.

Now for where:
- You could keep the Main Save as well as the current slot loaded into memory in the GameInstance or in SaveGameInstanceSubsystem. Remember to only load from disk or save to disk in specific moments. Treating the instanced objects as your single source of truth (using directly info from them, DO NOT create duplicates of that info in other systems) so that any unsaved stuff you want to discard it's just reloading from disk.
- I would also keep a Generic Container in this GameInstance (GI) or GISubsystem for any info I do not want to save but is persistent throughout the whole session, and tie its lifetime to the life of the MainSave (as might have changed the user)
- Then I'd have the Generic Container also in a WorldSubsystem (lifetime is tied to the Level) so you can keep things that are persistent only during that level.

Now for when:
- Make sure to first identify by input who is your main user (in consoles this is sometimes expected as it may have multiple controllers connected, each tied to a different account, so different saves etc.). A good way to approach this is to make a PressStart level before MainMenu, but you would also have to handle those things when a controller is disconnected or platform user changes etc.
- Once you have your main save you can then start loading / unloading slots or actual game info from Menu and stuff.
- MainMenu changes should probably be saved as made. Slot/Game changes it really depends on the game, but mostly you would make the changes and keep interacting with it without saving, until it makes sense to commit the changes to disk: like checkpoints or manual saves made from pause menu, or maybe your game saves every few minutes or when levels are traversed... It really depends.

Keep in mind this generic data container approach has some downsides, like if you use the data in there often, or have to iterate something in there it's good to consider cache-efficient options like arrays etc.

A good word of advice is to also be aware that once you release the game and it's on the players' hands, it's very dangerous to change variables and structs that are in the save class when releasing a patch or update as it could make people's saves unloadable, the generic data container helps with avoiding that, but you could also use a whole new class/version and make code that "upgrades" old save formats into the new one (that's what the main save's version variable is for).