I’m surprised you’re not interested in a community’s being able to collaborate on authoring/reviewing/editing a body-of-knowledge. SE claimed that one of its two intents was to build a resource for future readers, as well as for getting your own question answered.
The only way to read SE though is via Search or Google, or chronologically if you’re avid and there from the beginning, the different topics are unconnected; it’s only a tag cloud, like a reference manual with an index but no table of contents.
Another use-case, I guess, might be building expertise around an existing document – for an example, start with the completed/published manual of which this is one subsection, and then be able to ask questions about the contents of that document – “I’m trying to X and it doesn’t work?”, “I don’t understand how to use X?”, and, “Can I see an example of using X?”.
I do think it’s also within the scope of the what SE is used for – i.e. canonical answers to novice questions, which are literally the “frequently-asked questions”. Those canonical answers are tagged, and they are (should be) curated so that they may cover some topic and subtopics but without overlapping – eventually you can read them like a book (if you are the kind of person who reads FAQs, which e.g. programmers are) – therefore IMO information-which-evolves-into-a-book is in-scope.
I mean it’s fine if your idea of “community-driven Q&A” is limited and isolated like SE’s. But theirs is limited by design – of the UI, of the social interaction, and of the structure of the resulting data.
If you wanted to make “a better SE” then I thought that “a better Wiki” might be in-scope too – not to implement immediately even but to foresee how the MVP might want to evolve – to avoid baking the MVP in a way that prevents such extension.
I’m a little fearful of using a relational database, not because I don’t know how but because of how that might constrain what can be implemented. I’ve been interested in this problem (“documents”) for a while – I’ve been a technical writer.
In a previous personal experiment I found that “trees” (e.g. “subsections” and “threads”) do not play nicely together with “SQL” (and DDL).
https://www.amazon.com/Hierarchies-Smarties-Kaufmann-Management-Systems/dp/0123877334
Combining them seems to me a job for the clever, or the professional masochist with an unlimited R&D budget – or systems programmers who write database engines and their extensions, and not for application programmers.
There are vendor-specific (database-engine-specific) extentions for trees and XML – but.
And I think you see that in SE – that the product is constrained by SQL (as if its underpants were showing) – that it’s all datatypes and relations which are easily modelled as a relational database.
You said …
… but I just don’t see that as a good thing – not a best practice to be copied.