I do not see this issue; Firefox 31.

I still see this issue on link in comment 0 with Firefox 30.0:
"References" section ends with 25, last reference in text above is 33 though.

• I see this now. I stripped this down to a simpler exemplar:

<ref>1</ref><ref>2</ref>

<ref name="a1" group="u" /><ref name="a2" group="u" />

{{reflist|group="u"|refs=
<ref name="a1">ref1</ref>
<ref name="a2">ref2</ref>
}}

<ref>3</ref><ref>4</ref>

<references />

• But using <references> in place of {{reflist}} resolves the issue:

<ref>1</ref><ref>2</ref>

<ref name="a1" group="u" /><ref name="a2" group="u" />

<references group="u">
<ref name="a1">ref1</ref>
<ref name="a2">ref2</ref>
</references>

<ref>3</ref><ref>4</ref>

<references />

• I will look at this a bit more later.

As I suspected, #tag:references is involved. This example triggers the issue:

<ref>1</ref><ref>2</ref>

<ref name=a1 group=u /><ref name=a2 group=u />

{{#tag:references|
<ref name=a1>ref1</ref>
<ref name=a2>ref2</ref>

<ref>3</ref><ref>4</ref>

<references />

I have updated the title to better reflect the issue.

The problem occurs because the list defined references are missing the group:

<ref>1</ref><ref>2</ref>

<ref name=a1 group=u /><ref name=a2 group=u />

{{#tag:references|
<ref name=a1 group=u>ref1</ref>
<ref name=a2 group=u>ref2</ref>

<ref>3</ref><ref>4</ref>

<references />

We should be getting an error instead of silently mangling the numbering. I think that resolves this issue, but I will file a report for the missing error.

I can confirm this is still an issue in 2020. This is the most minimal example I can come up with:

<ref>should be [1]</ref>
<ref name="a" group="g" />
{{#tag:references|
<ref name="a">a</ref>
|group=g}}
<ref>should be [2]</ref>

Note that the last footnote marker becomes [3], when it should be [2].

Thanks to the ongoing Cite-Extends project I even have a vague idea what the issue is: The <ref> inside of the #tag function is rendered before the #tag:references. While processing this <ref>, Cite believes it will become number [2] in the article. But the moment the parser reaches the closing }}, it turns out this assumption was wrong. Cite contains code to detect this situation and rollback and redo affected <ref> tags. It looks like this rollback process does not rollback one of the internal counters. That's why it continues with [3].

Change 567014 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/Cite@master] Fix incomplete rollback producing bad footnote numbers

https://gerrit.wikimedia.org/r/567014

Change 567014 merged by jenkins-bot:
[mediawiki/extensions/Cite@master] Fix incomplete rollback producing bad footnote numbers

https://gerrit.wikimedia.org/r/567014

Change 567254 had a related patch set uploaded (by C. Scott Ananian; owner: C. Scott Ananian):
[mediawiki/services/parsoid@master] Sync parserTests with Cite, including new blacklist entries

https://gerrit.wikimedia.org/r/567254

Change 567254 merged by jenkins-bot:
[mediawiki/services/parsoid@master] Sync parserTests with Cite, including new blacklist entries

https://gerrit.wikimedia.org/r/567254

I think this may also be T124213: Nested references rendered in wrong order in reflist while ungrouped or the other connected task there which is T18330: When nesting refs using cite.php extension, the ordering is wrong.