These are just assertions, however. I liked your earlier comments because they are testable against the architecture (even if the current implementation, early as it is, will fail many of these tests). What real world needs cannot be met by a comment-centric architecture for .. commenting? How important are they?
Erik, a major property of a document-centric architecture that is lost in a structured one is that it's open-ended, which means that end users can build new features and flows on top of it, without the need to request the platform developers to build support for them (sometimes even without writing new software at all; new workflows can be designed and maintained purely through social convention).
That's not something that's easy to do when the basic raw material for communication is split into comments and compartmentalized as table records with different owners. Such change means that a community that now can handle their own growth is made to utterly depend on the developers as gatekeepers for its expansion. In a project where the development team is understaffed, that's not a healthy proposition.
Sure, you have proposed a Workflow management system in the works, but with all respect that's pie in the sky. That possibility is under-specified, would require a lot of research and development with unclear goals and requirements, and there's no guarantee that it would ever be fit for the purpose. Please understand why we are wary of such proposal as the solution for all the flexibility requirements.
Sincerely, it looks like you have this grand vision on how a comment platform should work, and there's this blind spot to it. Despite repeated attempts by several experienced editors trying to explain to you how this architectural change would affect the essence of the project smooth operation and well-being, you dismiss them by focusing on a single feature at a time and missing the forest for the trees.
The point is not how we could replicate this or that feature on Flow, it's how we allow support for all future workflows that we don't know about yet, without requiring that software changes are made to the platform for each new need. We know that Wiki systems are valid platforms to support such expansion requirements, because we have seen them working; but we don't know how the structured architecture will behave, and there's no reason to believe it would work - no other structured system have achieved anything similar. You ask "how important are these needs"? I tell you they are *essential* to the community; the existing encyclopedia couldn't have been built without this openness.
You asked Todd to make requirements that are testable against the architecture. Well, I have one: how well does it allow end-users to build new unforeseen workflows without requiring development of ad-hoc software and changes to the platform?
I hope you give consideration to this argument before dismissing it as inconsequential. So far it seems that the decision has already been made and that your question ("Do we want discussions to occur in document mode, or in a structured comment mode?") is rhetorical. I hope that this happens not to be true, and the decision is still open to debate from the community.