Here are the two function protoypes that David Baron linked to. I think they pretty much illustrate the point perfectly.

KHTML:
virtual void layout();

Gecko:
NS_IMETHOD Reflow(nsIPresContext* aPresContext, nsHTMLReflowMetrics& aMetrics, const nsHTMLReflowState& aReflowState, nsReflowStatus& aStatus);

And later, from David Baron:

Why is Mozilla's layout engine so big and complex? Perhaps the simple answer is that there were too many people available to write it, and they wrote as much code as they could. After all, they didn't have any incentives to keep the code small.

That's so true. Though I think "second system syndrome" is an equally important reason for Mozilla's total lack of urgency and closure: too many of the people involved (who liked to describe themselves as "architects", which is always telling) thought of the whole project as "finally, we get to rewrite it, but right this time!" and that attitude basically never results in usable, working code appearing before it's far too late to matter any more.