See attached testcase-01: there are three pairs of paragraphs numbered with counter and separated by horizontal lines.
In the style there is counter-reset "initialisation" done is the first rule for body and same reset is done at hr.
First reset (to implied zero value) is in fact unnecessary, because first counter-increment should initialise it anyway.
Later reset should restart counter after each separator, but has no effect on the actual outcome in Firefox 91 (and later).
Expected outcome: 12|12|12.
Actual outcome: 12|34|56.

If the first reset is omitted, outcome matches expectations, specs, other browsers and older Gecko forks.

Spotted at <a href="https://stackoverflow.com/questions/52470132/how-to-nest-multiple-counters-in-css/52470237#52470237">SO answer</a> as it, to my horror, started to produce unexpected outcome.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=33b1ed31c18a3066b2e41f1901f8221375a808dd&tochange=75559571662961f502e2f424cc3b2d7572c50bb5

Well I have revisited current specs draft [1] and if I understand them correctly, current Firefox is probably compliant here. (To my surprise, meaning of counter-reset dramatically changed and we now have to use counter-set in for, erm, resetting counter )

Changing second rule in the testcase from

hr { counter-reset: a }

to

hr { counter-set: a }

fixes the issue in modern Firefox and breaks it's older forks and other browsers not supporting counter-set. I'm really surprised to see breaking changes in CSS specs.

[1] https://drafts.csswg.org/css-lists/#nested-counters (Editor’s Draft, 14 July 2021)

(In reply to Michal Čaplygin [:myf] from comment #4)

Well I have revisited current specs draft [1] and if I understand them correctly, current Firefox is probably compliant here.

I think so, too. Hence, closing this as INVALID, since we match the spec.

(I think this is effectively the same as bug 1747428 and bug 1737103, and bug 1737103 comment 3 has some further explanation.)