Why Web Serials Break the Stock E-Reader Library Model

E-reader libraries are built on the assumption that a book is finished when it arrives. A web serial violates that assumption: it is a document that grows, sometimes for years, and the reader's position has to survive each round of growth. Sending an updated file to a stock Kindle library produces a second copy rather than a longer first one. The reader accumulates duplicates, and reading position does not carry across them. Following a handful of ongoing serials makes the library noisy; following dozens makes it unusable. The instructive part is where the fix actually lives. Switching to a better reader application does not solve it — KOReader on Kindle: KUAL, kindlepw2, and kindlehf has exactly the same problem if it is handed a new file each time. The fix is in the automation layer: a tool such as FanFicFare rewriting one EPUB in place, so the library holds a single growing document and the reader's own position tracking keeps working against it. This is a recurring shape in tooling problems. The symptom is visible in the application, so the application looks like the thing to replace, but the correctable cause sits one layer down in how content is delivered. Picking the layer to act on is the same judgement made at larger scale in Replacing an E-Reader's Userland vs Writing an OS: Three Tiers. One detail is not well documented and is worth testing before relying on it: whether a reader's per-book sidecar metadata — KOReader keeps reading state in a `.sdr` directory beside the book — reliably survives an append-chapters rewrite of the underlying file. Sidecars are known to follow renames and moves; the in-place rewrite case is less clearly specified. Verify it on a single book before trusting a large library to it.