We use a really specific sort of character buffer that Keith created, so it's not quite just a comma-separated list, though that's certainly a big part of it. Ints and floats and so forth are stored with pretty different sorts of data from what a pure text file would do. There are serialization and deserialization classes that you can call, but one of the key tenets of them is that no metadata is stored and so you have to know exactly what order to pull things out in, and if anything is even slightly out of place then the entire file is unreadable. This is a very efficient way of storing the data, because metadata about what each piece of data is is incredibly space-consuming when you're talking about that much data.
Granted, having some sort of "header area" that works differently would in theory be possible, but that's something Keith would have to come up with and make a callback for. That's worth a mantis request, for basically being able to insert arbitrary data in a certain subsection of the start of the savegame. A centrally-controlled callback for then passing you that data back as a string (or something) would then be something he'd need to create. The balance between efficiency and usability-for-modders is something he'd need to carefully engineer, so it's not a quick thing (unless it is, heh).
The other point I'd like to make in general is that including things like screenshot thumbnails is in general not a great idea in my opinion. To do a screenshot requires a screenshot to be taken (of course), which in itself is a pretty sizeable hitch in unity, and then you need to scale that down, which requires System.Drawing to work properly, and that creates a lot of garbage as well as more data. You then have to encode the data in some fashion, whether that's jpeg or png or whatnot, to make it not absolutely monstrous in size in the savegame itself. Embedding that isn't a problem, but the amount of a visual hitch you introduce any time there's an autosave is going to be notable.
If you're trying to get a screenshot of a specific thing (like the galaxy map), then you first have to switch the game to viewing that at the correct zoom, let it sit for at least one frame, then take a screenshot, then return everything to the way it was before you did that. Think of it like photography. I can't photograph the layout of your house without going to your house, taking off the roof, renting a helicopter, and actually taking the photo. Then I need to put the house back together, return the helicopter, go back to whatever I was doing before, and probably explain myself to you and the police.
There are some ways that we could make things like that easier if we wanted to, but there are a lot of complexities with that having to do with bounding boxes, field of view, offscreen cameras, and object active/inactive states. It would get rid of the worst of the "now we have to put things back" problem, but it would still cause a visual hiccup as well as a literal flash of some other part of the game. There are STILL other ways around that, but then we're talking offscreen cameras and render buffers and such... and that certainly would be more tractable and could avoid the visual hitching, etc. But you run into that potentially taking a week or more to figure out all the details of.
And at the end you have a tiny screenshot that probably looks pretty much like all the other screenshots, and the load game scene loads really slowly because of having to extract all that metadata, convert it to jpeg, then convert it to the unity Image format with DTX1 or DXT5 compression, and so on. That part would be wiiiiicked slow.
Anyhow, metadata is a lot easier to handle than the screenshots bit.
Usually for screenshots it's easier if the screenshot is saved next to the savegame as its own file, and if you don't have too many savegames. I did this in Shattered Haven, for instance. It worked well there, partly because there was no autosave, but also because each screen was visually pretty different.
