No, what I'm describing is a single .html (or .xhtml file, if you like), compressed and sent on its way. Editing it as a series of xhtml, css, img, and manifest files makes perfect sense -- it allows a human to craft a book using the level of tooling that makes the most sense for them (from a word document to raw html to markdown to more sophisticated tools) but all of those tools can then retarget to a monolith that is easy to define and consume.
They do; probably xhtml/XML is not really an ideal format because it isn't easily linearalizable, but if ereaders are using a reduced set of the functionality, then they can probably safely assume that they can just split the file at a <p> or <mpb:chapter> tag without loss of fidelity, and just consider that all style-related content needs to occur in <head>.
My comment below has some remarks on pagination and reflowing that mean that a reflowable HTML file capable of being rendered by an ereader is likely subject to certain restrictions on the content to make it work. There would probably have to be a one-time indexing job (noting paragraph and chapter breaks to allow random-ish access into the file) but I think that's not crazy even for a very large document.
