I’m not hugely familiar with restore code, but I think it’s oriented around backend files not source as backup is (but even there, I think the nice per-source-file UI wasn’t always there – sometimes UI displays improve).
There’s far from a one-to-one mapping of source to backup files, and a given source that’s updated many times will only upload changed blocks during backup, so they may be aggregated with others in the dblock. Restore downloads whatever dblocks are needed for the requested files, then takes them apart for blocks. Choosing sizes in Duplicati discusses the tradeoffs. 500 MB may be reasonable. Some go even higher, to avoid the perhaps-still-annoying-us 5000 file list view limit in OneDrive (go beyond that and see nothing…).
I assume that took the place of repeating the backup, and that the troublesome two files now restore. That reassures me because I’ve seen some odd upload behavior on recent canary to OneDrive, and am hoping that it’s just me somehow. duplicati-b685d9add203f4056b7cc7c8315fd5c77.dblock.zip.aes download error wasn’t well explained last time, but you could probably have seen the cause in About → Show log → Live at Information level or above. If there was a hash mismatch, you might have “fixed” it by importing the bad hash into the database during Recreate. To be extra cautious, you can try downloading the file and opening with AES Crypt or CLI tool SharpAESCrypt.exe in the Duplicati folder. But file restores are also good proof.