I think that’s right. I was using that to my advantage in 403 error during compact forgot a dindex file deletion, getting Missing file error next run. #4129 to force a cleanup after the compact didn’t handle errors correctly.
This is a problem because if you never compact, wasted space created by deleted files never goes away. Having it grow without bound might be kind of hard on the storage budget, and clutter up Duplicati as well. Having some sort of maintenance window might have been possible, but not with a restriction like above.
If you wonder about the compact concept and how things are stored, see How the backup process works which shows how features such as uploading only changes, and deduplicating similar file versions occur. Problem is that they don’t fit your model well because of the heavy processing from source to the backup.
So yes you can cover this largely by never running compact, but is the cost of indefinite buildup tolerable?
There’s another time when a delete “might” be tried. If file upload returns an error, Duplicati retries with a new file name, and may try to delete the file that returned the error. There’s some logic to look, but I’m not sure if it’s delete-first or look-first. Just saying potentially this is another issue (but not a proven issue yet).