When publishing a new minor version of an existing book (i.e. the structure of the book does not change, but the content of one or more pages does), the new book will need to be cooked. This will generate new versions of all the composite pages, that is, pages that are defined by the cooking recipe, not by the raw content, such as end-of-chapter exercises, end-of-book index or glossary, etc. Ideally, these new pages should retain their uuid, and only get a new version number. This is tricky, since the pages do not exist in the raw content that is sent to be cooked, so the rulesets cannot set thier ids. However, the rulesets do set a locally unique class on each of these pages. This, combined with which chapter a given composite page is in, is enough to identify that particular page across minor versions. So a combination of chapter-identifier and composite-page class can be used as a key to lookup uuids from the soon-to-be-one-version-old book tree, and assign them to the parallel page of the newly-cooked book. The wrinkle in this is what to use as the chapter-identifier. For historical (hysterical?) reasons, the tree form of our books does not contain a unique UUID identifier for each section (unit or chapter). Instead, they share the id 'subcol'. This will probably need to be changed to a UUID to solve the bigger vesrion of this problem (keeping ids across major version republishes). However, for the immediate problem, minor versions of the book, we can depend on the order and existence of the existing chapters, since changing those is a major version change. This allows us to use the relative position of the parent (i.e. chapter) of each composite page as a surrogate identifier.
I propose this be implemented as so. When a minor version of a book is published, the cooking code will be triggered. This code should check for an existing publsihed version of the book. If it exists (as it will for minor version changes), it should walk that tree, and build a dictionary of composite page UUIDs and versions, using the index position of the subcollection (chapter) within the larger book, plus the existing class attribute from that composite page. It is up to the ruleset/recipe to make sure that such a combination is unique. Once the book as been cooked, when processing the new single-page HTML, when assigning UUIDs to the new composite pages, calculate the same key, and see if a UUID exists, before assigning a new one. Then assign the same UUID, and increment the version, otherwise, continue as before, assigning a new, random UUID.
Alternatively, the ruleset/recipe could responsible for setting another attribute in addition to the class, that is guaranteed to be unique in the book, and is a logical identifier for the page across versions (something like 'chap3-homework', 'chap4-homework', 'eob glossary'). That would then be used in basically the same code flow as above, in place of counting chapters and using the class. It might work to just use the class, in fact - adding an additional class that 'counts chapters' and having publishing use the entire class string as the lookup key might work.