Answering in somewhat backward order, it sounds like the file and folder name are OK except for that .docx extension. The docs.checksum and the folders in the Data directory all sound fine; the folders would be named things like
37330BD9-0D35-4B33-A93B-EB8C793AFC7E and could be empty–the folder matches a binder item, but if the item doesn’t have any content (e.g. a folder you’ve created just to organize sub files, but it doesn’t have any text of its own), there would be no “content” file within it.
The “content.docx” indicates a problem, though. Scrivener uses .rtf files and any imported .docx files would have been converted, so it sounds like something happened either when uploading or downloading from Google Drive. Google does have ways to convert files, so although I’m not sure what the default settings are or how it would have handled this, it doesn’t seem at all impossible. Scrivener wouldn’t recognize them, so loading the corresponding binder item would give you an empty editor.
The “Recovered” files are documents that Scrivener finds within the project’s folder that don’t exist in the index, so it doesn’t have a way to match them with existing binder entries and creates the new entries for them. Since they are being recovered, at least we’re assured your text is in there, even if it’s not all recognized in the place it’s supposed to be.
Are you able to see within the project’s .scriv folder on Google Drive and determine if the files are RTF or DOCX there? My guess is that the conversion would’ve been on upload, but if they are still RTF there, maybe there is a setting you can change that will enable you to download the folder without that changing. (And yes, I believe Google Drive always zips folders when you download them.) You could also check if there’s any sort of file history for the items that would let you roll back to a version before it was converted.
If neither of those works, you may be stuck with some manual cleanup. Going back to your initial post, it sounded like all the text of your project is present, just out of order and no longer matching its original binder title. But you also said it couldn’t be copied and pasted–does this mean Scrivener’s treating it as some kind of uneditable document in the editor?
If you like, you can send a copy of the .zipped project to the Mac tech support email (or send a link to download if, if the file is over 10MB) at mac.support AT literatureandlatte.com ATTN: Jennifer and I can take a look. I may not be able to clean it all up for you, since I won’t know what goes where, but we can at least get a better idea of what’s in the project package and how to sort it out.
Moving forward, there are a couple of things to do to avoid the problem in the future. First, be sure that you have the automatic backups enabled in Scrivener’s preferences and that you’re saving them to a location distinct from where you’re keeping the active copy of the project that you’re working in. (In fact, Scrivener tries to prevent you from having these in the same place, so I may be misunderstanding how you had your backups vs. main project stored. If your backups were on the desktop, where is your working project stored?)
I highly recommend using the zip option for the backups, as it helps prevent you accidentally opening and editing the backup and also compacts the project folder into a single file that you can then move or copy to another drive, sync to a cloud service, etc. without the complications of working with multiple folders and files. (Although macOS treats the .scriv folder as a single file, it is really a folder of numerous files, as you’re seeing.)
Also look over the settings in Preferences > Backup to be sure they fit your work style–e.g. the default is to create a backup when the project closes, but you may prefer to make it on open, or also trigger it with the Save command. You can likewise choose how many backups to keep before old ones are deleted to make room for the new. You want to have a system that will give you a decent selection of backups to choose from if something goes wrong, so if you’re a compulsive Cmd-S typer, triggering a backup with every Save wouldn’t be a helpful choice.
If you want to store backups in Google Drive, having them zipped before uploading will be your best choice and will avoid any of these weird conversion or renaming issues occurring within the project. If you have the desktop app such that you could save straight to Google Drive and wish to do so, creating the backups as a zip should do the trick. Once you have your project cleaned up, you can test this by creating a backup, then closing the project, downloading the backup from Google, extracting it, and opening that project backup to make sure it works right. If it does, trash your downloaded copy and you’re good to go.