I think the newly found bug caused by RM 10’s Relationship Chart report is indeed responsible for most, if not all, of the unexplained losses you were plagued with and it had nothing to do with FamilySearch or TreeShare or cloud-synching… It is an unexpected quirk caused by the programmer switching SQLite away from atomic transactions that update the database disk file on the fly to a batch process for which transactions are accumulated in-memory but have to be committed to the drive en masse by an explicit command. The report generator seems to start the batch mode but fails to complete it and so new data happily builds up in the in-memory database without being written to disk and is lost on closing the database. It is also lost after running the Chart with some other operations such as Compact and maybe, from your description, by TreeShare. Hopefully, the coming update will enable you to gain confidence and I’m sure you will tread carefully.
Sorry for all the attention I gave to OneDrive as the possible cause.