Some replication process at Google had fallen behind by 6 months (and presumably didn't have monitoring/alerting), and someone noticed and in trying to fix it they forced that replica to take mastership (meaning the users now see the 6 month old data).
Since the replicas presumably now have conflicting changes, re-merging the two is going to require a lot of code be written to smartly merge the data, and some users are going to permanently lose data (where they edited an old version of a document for example, and those edits cannot be automatically rebased onto the new version)
You could... But writing and deploying a diffing tool for every different gsuite application is probably 6 months of work for a whole team... There are so many corner cases.
What will the users do for 6 months waiting for their data to return?
I guess there may be a bevy of different file formats and a diff for a spreadsheet an an image would require building tooling, just from those examples. I was thinking of creating an application where the front end is more than just a file browser to stored file types but the interface to read/edit the content as well.
You don't even need to go that deep -- just give me a filetype-based icon, file name, and last modified date, and that should be enough for me to choose. And if they want to be simple, include the option to always keep the most recent version of the file (which is going to be the right answer in many cases).
That seems like one of the more unlikely causes, among the almost infinite variety of causes that are consistent with "several people said they can't find some files".
To me the most likely one by far is the deletion was actually commanded, for example by a flaw in the program they use to sync, or by malware.
I am still skeptical that users are correctly describing the behavior of a multi-party synced filesystem, or that Drive for Windows is bug-free. You seem to think it's a flaw on the backend but I think there are many other possible causes.
Some replication process at Google had fallen behind by 6 months (and presumably didn't have monitoring/alerting), and someone noticed and in trying to fix it they forced that replica to take mastership (meaning the users now see the 6 month old data).
Since the replicas presumably now have conflicting changes, re-merging the two is going to require a lot of code be written to smartly merge the data, and some users are going to permanently lose data (where they edited an old version of a document for example, and those edits cannot be automatically rebased onto the new version)