This is actually an intentional optimization. Users may merged CSS/JS files together and wipe out what they took the code from, lowering the total assets that need transferring to a client.
It shouldn't be possible to accidentally write 0 bytes to a file. I'd have to analyze the code again to ensure that, but barring a real-world condition of there being a problem causing a reevaluation, I think the issue should remain closed.

Yes there is a real world example (though it's on v10, not v11; have not been able to confirm if this still exists on v11 due to lack of production use)... sometimes after a comcode merge from git, when the cache is cleared, it fails to properly re-build, resulting in "the requested page gave no output".

It sounds to me like this is Git writing out to a file on disk, but not doing an exclusive write lock while writing the file. Therefore when Composr reads the file it doesn't have to wait until Git finishes writing, and renders with an incomplete (perhaps, blank) file.
Fix might be to have a Git post-update hook that calls decache.php.

I believe there already is one, but these hooks don't seem to be running. I know we have hooks for compo.sr but I always get warnings that they're not being run. I'll have to replicate the exact error.