I think this problem is manifold. First of all, I've discovered that HtmlHeaderContainer renders a StringHeaderItem at line 230. This should be a PageHeaderItem. Secondly, I suspect that StringHeaderItem and PageHeaderItem should not override equals and hashcode. The argumentation for this would be that these are free-form and therefore no assumptions can be made about the semantics of the contents. With duplicate JS or CSS references, it is clear that duplicates should not be rendered, but as can be seen in this case, duplication has no meaning for StringHeaderItem. Finally, it seems that HtmlHeaderContainer.renderNext is not needed at all. This is the method that splits the headers into many small parts.
The first observation should be fixed, because it is a bug.
Removing the method that splits the header items, fixes this ticket. It breaks 2 others, but only because some whitespace in the header changes.
Changing the second observation fixes this bug, but breaks a testcase: HeaderSectionTest.renderHomePage_20(). This testcase renders a StringHeaderItem in a component that is added twice. Changing the equals causes the item to be rendered twice. Perhaps StringHeaderItem should be rendered once per component class, but the HeaderItem does not know the class of the component. In all, changing this right now probably breaks applications, so we should probably opt for the other solution and leave this as is.