There's a lot of human judgement and communication involved, sometimes. But mostly, error reports are enthusiastically accepted. And, very often (nearly always), updates to fix one set of reported errata usually lead to further updates. It's a positive feedback loop.
This is complete nonsense. I have been pointing out for years -- "error reporting" -- that almost all PG submissions have HTML formatting issues which make them unpleasant to look at and unpleasant to read on most ereader devices -- once run through the epubmaker "sausage maker" -- and nothing has been done to fix the problem. PG and DP have this NEGATIVE feedback loop where they fall in love with their own religion, drink their own Kool-Aid, and are then are incapable of seeing straight nor moving forward.
In fact, the biggest problem with HTML as a master format is that it is (mis-)used for layout, not just structure. This is actively discouraged. At http://upload.pglaf.org, we request that the uploaded master should convert well to other formats, using epubmaker. While this is intended to avoid layout choices that don't map well to other formats, it is not extensively verified, by human or machine.
And you are continuing to ignore that epubmaker is a big part of the problem. When a submission is made that say wraps a simple paragraph structure with a <p> then that paragraph structure *IS* properly marked for structure. Now mind you the style settings in that HTML file may not represent the most knowledgeable choices for compatibility for all ereader devices, but the algorithms used to map HTML to EPUB or to MOBI is something that PG has reserved exclusively for itself, not for the transcriber nor for DP. Thus failure of simple paragraph layout once run through epubmaker, for example, is a failure of PG, *NOT* of DP nor of the transcriber. Most of these problems can be simply and mechanically fixed by hand, which means that most of this could also be fixed by epubmaker. But this hasn't happened, because PG remains incapable of recognizing when it has a problem, let alone acting to fix that problem. Please note that other publishers, including for example Amazon, are taking these same PG HTML files, running them through their own "sausage maker" chain, and producing better results than PG is getting from epubmaker. There are a lot of ways the formatting issue *could* be fixed, but the reality is the problem is *not* being fixed. And that is a failure on the part of PG, primarily. Certainly there is a contingent at DP who also contribute to the problem by insisting on writing HTML which is only compatible with large screen desktop computers -- and even then only on a couple of the more popular browsers. But even that problem could be solved simply by having the WW'ers "sanity check" the HTML submission on a variety of very different size and shape displays, and rejecting the submission if it doesn't properly scale. But PG isn't even doing that.