I was able to reproduce a settings loss (not sure if it's the same thing as this), and what's happening is that the DiskId JSON files are getting corrupted sometimes if the system crashes / blue screens. In my case, they contain all NULLs.
The StableBit Scanner detects this on service start and generates new DiskId files for the affected disks, but that means that any persistent data associated with those disks is now gone (hence, settings loss).
I'm not sure what we can do to "fix" this, since technically it's not a bug. If your system crashes while an app is writing data to the disk, then that data is at risk of getting corrupted. What's interesting in our case is that we're only writing those files on service startup and when a new disk is connected. The writes are very simple, open a file, write the text, close the file, standard .NET code. So it's not like we're keeping those files open or constantly overwriting them, and yet, Windows does sometimes corrupt them on an unclean shutdown.
One potential (bad) way to "fix" this would be to perform a volume flush on the system drive after every file write, but this would be atrocious in terms of performance. It would slow the entire computer down significantly. NTFS transactions is another thing I looked into but:
"Microsoft strongly recommends developers utilize alternative means to achieve your application s needs"
"Furthermore, TxF may not be available in future versions of Microsoft Windows"
...but other than that, I'm open to suggestions. As with any potential fix, I'm very concerned about the performance impact, and I wouldn't want to implement anything that slows down the system drive.