I advise against multi-user support.
We should copy the way Lix handles this.
I ditched profiles from Lix in 2018. I write the username (important for replays, network games, ...) into the single options file. When you change that name in the options, all other options and trophies remain.
I find in-game multi-user-support purely a feel-good feature for devs, to make us feel like we're getting really important work done. I implemented multi-user in Lix ten years ago, I thought it had to be really important and solve lots of problems. But nobody ever needed it in Lix. And nobody had asked for it, neither before the impl or after the cut.
Also it's a source of confusion first, and bugs second. Confusion because you need a global file to store current username, and then an extra file per user, even if it's just one user in 99,x % of cases; who will want the feature anyway? Any of the devs that shares a computer? No? Then who from the nondevs has asked for this feature?
If two people are already sharing a session (of login in an operating system), they won't bother changing the user in the NL options. They'll merely play with the current name, and solve levels together.
Windows is particularly confusing. Assume you have NL in a no-writeable dir: Can happen when you're logged in as a non-admin because you happen to care about security, or, even less likely, because you have several user accounts on your home machine and thus want privacy w.r.t. other machine users. Then Windows generates written files in
your hidden user dirs anyway, C:\Users. And then your NL global options file goes into that Windows per-user dir, and the NL per-NL-user options go into that Windows per-Windows-user dir. You'll duplicate effort and confusion that the OS has already solved/inflicted on you.
I don't even
expect multi-user support by any application, I expect apps to rely on the OS.
Please carefully consider:
You can remember a player name as a normal option (without multi-user support).
You can move options/trophy files to get any perceived benefit of multi-user support.
To test options code automatically, you can refactor and isolate (no need for user features).
Why is this not enough and we need the complex feature instead?
-- Simon