When a <ref> tag is wrapped in a {{#tag:references|…}} parser function the parsing of the outer reference list is delayed. The inner <ref> tag is parsed first without knowing the outer context of the reference list. This is internally un-done (via a so called "rollback stack") and re-done, this time with the correct context.

This is how {{reflist}} works.

The problem is that a sub-reference possibly (not always) creates two new items in the internal data structures. But there is no code that can ever roll back more than one. This causes various glitches. For example:

• Either the main ref or the sub-ref will be marked as being used twice (visible via the "↑ a b" backlinks), even if they are never re-used.
• Only the sub-ref is rolled back and re-done, but the main ref is not. The main ref will show a behavior that doesn't make sense for a list-defined ref.
• A previous, technically unrelated ref is not rolled back correctly and shows a behavior that doesn't make sense for a list-defined ref.
• Numbers are consumed twice, creating gaps and mismatches between footnote markers and reference list.

This is an actual flaw in the current implementation (for the legacy parser). It's an edge-case we will probably not run into during user testing and such. But it should definitely block any larger deployment. We know that communities like enwiki where {{reflist}} is used will definitely run into this.

First steps:

• Add parser test cases that use both {{#tag:references|…}} as well as {{#tag:ref|…}} in various combinations.
• Make sure to cover especially situations where the rollback/redo logic from the old parser implementation kicks in. This happens especially when normal <ref> are wrapped inside {{#tag:references|…}}.
• Identify issues related to the fact that one sub-ref can actually create two entries in the internal data structures.