I also use the Shared Object for save data and have noticed times where the data appears to be lost or modified. For my cases where this happened, I tracked it down to the built in cloud data restore feature of Android. Google Play periodically and without ability for the user to control, will take a snap-shot of the data associated with an app. So, when I’m developing and testing (ex: replacing the app with newer version) typically the data is wiped for the new install, but then will re-appear with the cloud-imprinted save data at some later point in time. I have not experienced this affecting an end-user.
Per my findings, SharedObject data gets stored on Android in the Application Storage, not the Cache (which I tested by using the Clear storage / Clear cache options in the application Storage menu accessed by tapping and holding on the app). For my game, I explicitly use the cacheStorage for graphics files that are rasterized by the app at runtime by setting the file path with File.cacheDirectory.
I know that Apple, for instance, has some strict requirements around the types of files that get stored in applicationStorage vs. the cacheStorage (so as not to have all recoverable items like DLC being backed up on the cloud) and I suspect there are detection mechanisms in place on both Android/iOS to ensure files marked for cloud save are not too large. Based on your description, I doubt your SharedObject file is exceeding the limit, but perhaps if you are storing other files in the ApplicationStorage instead of the cache folder, it could be triggering such a mechanism and forcing the app to clear its data when file space is required by the OS.
I wanted to suggest this since it would have the same effect of wiping saves even if you switched to writing to a ByteArray file. Thanks for sharing this and please keep us updated on your findings/solutions.