And we should call it 'TalkpageHandler'. Because ContentHandler. Duh.

Or 'Unstructured Discussions'. And have it do absolutely nothing but display talkpages totally as usual, but with some extra handling so users don't need to muck up all their threading themselves.

And then when the users yell at us for doing this instead of, say, fixing all the actually broken stuff, well, who cares? It's not like they're paying us. >.>

The main feature is probably voting support. How many kinds of votes do uncyclopedians even do?

Main ones that come to mind:

• Tables with separate sections, tied to a gadget for actually submitting the vote (VFH, VFP, VFD)
• Ordered lists with separate for/against sections and a {{s}} 'score' item at the top (VFS, some forum votes)
• Unstructured/unordered lists with {{for}} and {{against}} together, and a {{s}} 'score' item at the top (other forum votes)

Four things users can do with it:

• Normal reply
• Initial comment
• non-comment section (which can still be replied to or even signed, but isn't inherently treated as a comment, and is also probably not a vote)
• vote section (also repliable, but with buttons or something for VOTING DUH)

Votes, general threads, and an entire thread block should all be embeddable objects (though maybe that last one just is the content model and we just use MCR to make that fly, I dunno).
Votes and discussion threads need to both be embeddable, inside each other or other votes/threads. Potentially indefinitely. Let's not limit people, here.

Okay, we are going to do this using slots. It is decided.

NOPE THAT WON'T WORK.

Because you can only have one slot of a type per page!

Is this primarily for the English Uncyclopedia? It sounds like it (or something like it) could be useful for the proposed Wikimedia talk page improvements, although obviously that project is still in the planning phases.

Note that storing all threads, or all messages of a thread, on a single slot, will make conflict resolution harder, depending on how the edit is handled (2 or more users adding or editing comments of the same thread)

In T220765#5212213, @Ciencia_Al_Poder wrote:

Note that storing all threads, or all messages of a thread, on a single slot, will make conflict resolution harder, depending on how the edit is handled (2 or more users adding or editing comments of the same thread)

Well, we wanted to store it separately... Though it appears MCR only allows for one slot of a given type per page (this is enforced by a key in the DB, so there's no way around this). Best part is, many slots of same type per page were included in the original MCR RFC as one of justifications for introducing MCR in the first place.
Aaaanyyywaayyy, we pretty much have to store it in a single slot. Unless we don't understand anything about MCR, which is possible.