When "Template:Multiple issues" is not used, results can be confusing:
The current implementation assigns the highest priority icon to all the issues in the ambox like so:
{F24904115}
The expected behavior is that each issue would retain its original icon.
= Precursor
[] T206177 talks about a more sustainable approach to handle severity and icons. It would be wise to talk/implement that first.
= Developer notes
Right now our code assumes that there can be only one section per page issue and that an icon is decided by the maximum severity of issues in that section. We have already accumulated a lot of technical debt with trying to parse issues and this would further complicate this.
An icon is extracted from a box here:
https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/master/resources/skins.minerva.scripts/pageIssues.js#L96
and rendered here:
https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/master/resources/skins.minerva.scripts/pageIssues.js#L173
If extractMessage also returned the element associated with it as part of a <IssueSummary>, in theory during rendering we could iterate through the resulting issues and wire up every single one with the appropriate message:
https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/master/resources/skins.minerva.scripts/pageIssues.js#L169
However, since issues also contains collapsed multiple issues, we'd need to be careful not to append icons to children who are part of a multiple issues block. Although issues do have isMultiple tag, the children do not.... this is where it gets messy.
Given severity is important to instrumentation, complexity is added if we need to still support the AB testing code.
There are some quick solutions to this task:
1) Decline this task, edit pages we identify that exhibit the problem. Find a way to flag this problem to editors e.g. T200880
2) Only show the first issue, hiding any adjacent issues (easily done via CSS selector). Possibly cause confusion.
3) Retain icons, but don't change behaviour (hopefully a small amount of work that benefits few pages but no promises)
Note: We will not be programmatically collapsing these. That would be significant tech-debt.