I'd love to be able to consume this fantastic information you've created and provide an alternative visualization for it. For that, it would be far easier to consume a database that has discrete change entries with fields like: version, category, title, class, method, summary, overview, reason, discussion, documentation, example_code, notes, and so on.

The contents of many of these fields could/would be Markdown, and the full Markdown or HTML as present today could be generated from them.

Pros

1. People (like me) could consume the core data programmatically more easily
2. I think it would be more clear how to add new features in a consistent manner.
3. Would allow slicing the data different manners, e.g. creating a view that covers only the String class across all versions, or only the changes from 3.0 to 3.1.
4. (maybe not a pro?) The visual presentation would be forced to be consistent. For example, Notes: vs. Note:

Cons

1. A fair bit of scraping work (or manual conversion) would be need to convert the existing data
2. Removes the ability for custom presentation for a specific item, if desired. For example, if there was only one notes value per entry, or one example_code section, but you wanted two separate notes labeled separately.
3. Hand-editing Markdown-in-YAML does not have nice Markdown syntax highlighting.