book as nested chapters vs. separating chapters and ordering

Problem

I've tried to look around for context behind the nested structure of the book, but please excuse me if I haven't looked carefully enough.

Currently, a book is a nested collection of Chapters (or BookItems). I figure that this has been driven by SUMMARY.md being a nested list. However, I haven't been able to find the background, or the discussion behind this, so I don't really know the pros and cons.

In some cases, the nested structure creates obstacles: the iteration (esp. mutable iteration) is achieved through a lambda, rather than an Iterator. It also makes look-ups between chapters cumbersome (if there is processing dependent of different chapters). I also figure parallelization would become difficult (for independent chapters).

Proposed Solution

An alternative would be to separate the handling of the SUMMARY.md -- the ordering of BookItems -- and the content (Chapters). Say:

struct Book {
  chapters: HashMap<Id, Chapter>, // or just a Vec...
  summary: Vec<SummaryItem>,
}

enum SummaryItem {
  Chapter(ChapterItem),
  Separator,
  PartTitle(String),
}

struct ChapterItem {
  id: Id,
  sub_items: Vec<SummaryItem>,
  // ...
}

This would make it kindof straight forward to create a (mutable) iterator on Book (for Chapters), but might make it more cumbersome to programmatically add/remove Chapters.

I'm probably missing some important points, so please let me know!

Notes

No response

Start by reviewing the current nested Book/Chapter model and how SUMMARY.md represents ordering. Compare that structure with the proposed separate chapters and SummaryItem design, and determine whether a concrete redesign can be agreed on; done would require a decided scope rather than only a discussion of trade-offs.