I still think that the main slot doesn't really need a special SlotRoleHandler. The very name "main" implies that it's the main content of the page that other slots extend, work with, or augment.
What are you thinking that any SlotRoleHandler for the main slot would actually do that wouldn't be handled as well by setting $combinedOutput to the main slot's ParserOutput before processing all the rest of the slots?
I want to avoid as much special casing for the "main" slot as possible. In my mind, the concept of a main slot only exists for backwards compatibility, and it should become less and less special over time.
We will probably want SlotRoleHandler to take on several other minor responsibilities in addition to combining output - e.g. determine countability, and perhaps other things that currently reside in ContentHandler.
Essentially, not having a SlotRoleHandler for the main slot would be as awkward as not having a ContentHandler for wikitext. Lot's of "if main do this, otherwise do that" all over the code.
It seems highly unlikely that we'd have "if main do this, otherwise do that" all over the code. At worst we'd have a "getSlotRoleHandlerForSlot()" method of some sort that would return a generic handler for the main slot.
That generic "getSlotRoleHandlerForSlot()" method and generic slot handler is exactly what I'm proposing. The only question is whether it's the same handler regardless of content model. And I would leave that decision as an implementation detail. Code that uses the slot handler should not know or care.
