Sparkle attempts to mitigate the possibility of a broken/incomplete website and to date we have actually had no report of that happening.
The way it’s done is all brand new files are published in their final place, but all files replacing existing ones are published to a “sparkle_upload” folder. Finally all replacement files are moved in their final place, and no longer used files are deleted.
In practice images are always generated with a new name if their content is changed (this is for unified cache coherence from within Sparkle’s compressed image cache all the way to the user browser), so images always go to their final place. Smaller css/js files are also revved (in this case to prevent browser caching not reloading them), and end up in their final place. html files got to the sparkle_upload folder and are moved into place around the end of the publishing process.
So unless that last rename step fails or is interrupted, it’s either the old site or the new site.
I’m not sure what you mean with buffer space, but because of the technique above, 200MB of new content will sit along side the old content until publishing completes, so the total space used would peak at 1000MB, and go back down to 800MB when the publishing finalization clears the now unused files.