Your point about users' remarkable ability to misinterpret features to their own sorrow is well-taken, @lunk. But this sort of thing comes up all the time regarding Big Scrivener now—people opening projects inside the backup folder, forgetting where their projects are on their hard drives, etc. Yes, of course, L&L should carefully build their UI design should they decide to implement this.
@krastev, It wouldn't take long to fill up even a maximum storage iPad Pro with backups of a 10 Gb project! But again, I'm thinking there would be a limit for how many of these are kept just as there is for Big Scrivener. As for how long it would take to archive such a project, well, I'm not going to experiment and find out.
. But even in the current thread about sync crashes, the projects deemed "large" are generally in the tens of Mb, not Gb.
*Digs out iPhone and stopwatch* It just took me 21 seconds to make an archive of a 13 Mb project with 2445 files in, on an iPhone 8 Plus. That's really fast compared to how long it takes to sync. The archive weighs in at 5.3 MB.
Part of the problem here is that I believe, @lunk and @krastev, that you are thinking Mac or PC centrically. This would greatly benefit the iOS-only users. Making a backup is so buried in the iOS Tutorial that many users don't get that far, or their brains skip over the one parenthetical phrase that mentions it! The focus is on sync, sync, sync. And not even syncing between iOS devices, which in my experience has had more problems than syncing between iOS and Big Scrivener. Yes, this would be an option in addition to regular syncing, or instead of it.
One that actually takes less time than syncing, with its "downloading file list", and which preserves the iOS version of the project in the case of sync gone wrong. My vision for this is that the order of operations would be backup then sync.
This is of particular benefit to the crowd who just plain hate Dropbox. An archive file is safe to store on even project-mangling cloud services (I'm looking at you, Google Drive). This would give Dropbox-haters a semi-automated way to transfer projects among their various machines, using any cloud service that integrates with the Files app.
Ideally, L&L would provide an iOS "share sheet" that would accept a zipped archive, de-archive it, save it as a project if it's a project, or discard it with a message if not. I do that now with a Shortcuts app share sheet and it works great.
Yes, there are many design decisions for L&L to consider. I think that the potential benefits for iOS users outweigh the drawbacks, or I wouldn't have posted. I'm content to leave the decision to KB and the L&L design team.