This is enough to show the error, without involving any templates or LUA code:

{{#tag:ref|<cite>The citation goes here</cite><templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>|name=X}}
{{#tag:ref|<cite>The citation goes here</cite><templatestyles src="Module:Citation/CS1/styles.css"></templatestyles>|name=X}}

References

<references/>

Huh, nice job tracking that down.

I guess TemplateStylesHooks::handleTag could have its own internal "seen" cache and assign a unique marker index to every style, instead of incrementing mMarkerIndex for every <templatestyles> tag encountered?

The number of articles listed in Category:Pages with duplicate reference names continues to grow, I guess as the safe copies of the cache expired.

IMO it would probably be better to fix it in Cite, by having it unstrip markers when testing for exact duplication.

Near this line, make the code look like

$stripState = $parser->mStripState;
if (
    isset( $this->mRefs[$group][$key]['text'] ) &&
    $str !== $this->mRefs[$group][$key]['text'] &&
    $stripState->unstripBoth( $str ) !== $stripState->unstripBoth( $this->mRefs[$group][$key]['text'] )
) {

In T205803#4630028, @Anomie wrote:

IMO it would probably be better to fix it in Cite, by having it unstrip markers when testing for exact duplication.

Near this line, make the code look like

$stripState = $parser->mStripState;
if (
    isset( $this->mRefs[$group][$key]['text'] ) &&
    $str !== $this->mRefs[$group][$key]['text'] &&
    $stripState->unstripBoth( $str ) !== $stripState->unstripBoth( $this->mRefs[$group][$key]['text'] )
) {

I would tend to agree the more-appropriate fix is in Cite than in TemplateStyles.

Can we please revert the offending change?

In T205803#4663276, @Hawkeye7 wrote:

Can we please revert the offending change?

https://en.wikipedia.org/wiki/Help_talk:Citation_Style_1 would be the place to make this request.

Change 467109 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/Cite@master] Unstrip <ref> contents before comparing

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

If there was no change to the MediaWiki software that caused a problem then there is no need for this change.

In T205803#4664752, @Hawkeye7 wrote:

If there was no change to the MediaWiki software that caused a problem then there is no need for this change.

Huh? No, that's not how that works. Sometimes we find not-great behavior in the software that is illuminated by the intended use of some other function.

Not-great behaviour is not bad behaviour, and the risk involved in changes like this is high. Such changes need to be very carefully considered and tested. The risk to reward ratio is too high.

In T205803#4664752, @Hawkeye7 wrote:

If there was no change to the MediaWiki software that caused a problem then there is no need for this change.

The change to the MW software was the introduction of Template Styles. There appears to be a bug in its implementation that was brought to light when en.WP started using this new feature in one of its templates. We are asking for that bug to be fixed.

Over the last 12 hours (or so) there has been a significant drop in the number of topics in Category:Pages with duplicate reference names. I don't see here any notes that indicate an intentional fix was made. But I also note that all I know about the mechanisms involved came from researching this issue.

I note that the fix doesn't seem to be particularly complete. For example, Template:Wikidata revenue still seems to be adversely effected and generates duplicate reference name errors for multiple invocations within the same article when those invications were previously safe.

It's certainly true that complicated, flexible software sometimes has unintentional interactions beteen apparently disassociated features. However, it doesn't seem very responsible to make a breaking change and then leave it there without initiating a request to have the newly-identified problem addressed. Or, without offering to roll back the change that revealed the problem. It seems that this issue is exposing either a weak process or evidence of a political problem -- where someone wants to get something fixed by torching it first.

Whatever the root cause, it doesn't seem acceptable to make a breaking change and then ignore the results for two weeks.

In T205803#4665823, @Mikeblas wrote:

Over the last 12 hours (or so) there has been a significant drop in the number of topics in Category:Pages with duplicate reference names. I don't see here any notes that indicate an intentional fix was made. But I also note that all I know about the mechanisms involved came from researching this issue.

The drop comes from editors carefully kludging around this Mediawiki bug. The kludges are designed to be removed when this bug is fixed. Nobody has been ignoring anything. The bug was reported, and a patch was uploaded two weeks later. Compared to some of the more serious phab tasks I follow, that is an amazingly quick turnaround.

I'm sure there's a lot that I don't know about the developmnet process used by this project. For example, I don't understand what "a patch was uploaded" means. I guess it doesn't mean that a fix was actually deployed, because if the fix was live, the kludges wouldn't be necessary.

When I say the results were ignored, I'm refering to the negative aspects of the original breaking change. The negative effects were evident before this issue was opened. If A is dependent on B, and A is changed to reveal a bug in B, it's my opinion that both A and B have a bug because they're incompatible. Sure, B should be fixed, but the change to A should be reverted until the fix in B can be implemented and both the initial change to A and the accomodating change in B are released at the same time. That might seem slow, but it results in better stability -- where kludges aren't required to patch over a regression.

Here, the negative effects caused by a change in A seem to have been ignored until this issue drew attention to them. Or, maybe they weren't known until this issue was opened. Because of inadequate testing, perhaps?

With the kludges in place, how will the effects of the patch be tested? How can site disruption be avoided (or at least, minimzed) in the future?

Please feel free to ask general "how does/should development work" questions in a forum or mailing list, as they are not directly related to the very topic of this task. [offtopic]: In short, patch upload happens in Gerrit. For deployment of code on production servers, see Deployments etc. For testing on servers before hitting production, see Beta cluster.

Change 467109 merged by jenkins-bot:
[mediawiki/extensions/Cite@master] Unstrip <ref> contents before comparing

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

In T205803#4663276, @Hawkeye7 wrote:

Can we please revert the offending change?

The "offending change" was people on-wiki starting to use <templatestyles> in templates that are used inside <ref> tags (or, more specifically, ref tags created with {{#tag:ref}}).

In T205803#4664752, @Hawkeye7 wrote:

If there was no change to the MediaWiki software that caused a problem then there is no need for this change.

This is incorrect. It should be possible to use <templatestyles> in templates that are used inside <ref> tags.

In T205803#4665025, @Jonesey95 wrote:

The change to the MW software was the introduction of Template Styles. There appears to be a bug in its implementation that was brought to light when en.WP started using this new feature in one of its templates. We are asking for that bug to be fixed.

There's actually no bug in TemplateStyles here, it's a bug in Cite's duplicate handling with respect to strip markers that hide the same text. It could be reproduced without TemplateStyles by something like

{{#tag:ref|<nowiki>abc</nowiki>|name=baz}}
{{#tag:ref|<nowiki>abc</nowiki>|name=baz}}

<references/>

In T205803#4665823, @Mikeblas wrote:

Over the last 12 hours (or so) there has been a significant drop in the number of topics in Category:Pages with duplicate reference names. I don't see here any notes that indicate an intentional fix was made. But I also note that all I know about the mechanisms involved came from researching this issue.

It was most likely a change on the wiki. Perhaps Special:Diff/864009635.

However, it doesn't seem very responsible to make a breaking change and then leave it there without initiating a request to have the newly-identified problem addressed.

This task is that request.

Or, without offering to roll back the change that revealed the problem.

As noted above, there's no change in MediaWiki to roll back. It's the use on-wiki of TemplateStyles within Cite references that is causing this.

In T205803#4666002, @Mikeblas wrote:

I'm sure there's a lot that I don't know about the developmnet process used by this project. For example, I don't understand what "a patch was uploaded" means. I guess it doesn't mean that a fix was actually deployed, because if the fix was live, the kludges wouldn't be necessary.

"A patch was uploaded" means that a developer created a software patch which is intended to fix the problem in the code.

The next step is for another developer to review and test the patch, with the eventual goal being that the patch is "merged" into the code. I just did that, BTW.

After that, the new version of the software has to be deployed. For Wikimedia wikis, this usually happens via the weekly "deployment train", as explained on enwiki's page WP:ITSTHURSDAY. For this task, that deployment should happen this week, October 16–18. If the issue is considered important enough to fix immediately, anyone is welcome to follow the instructions at https://wikitech.wikimedia.org/wiki/SWAT_deploys#How_to_submit_a_patch_for_SWAT to have it deployed sooner.

The Phabricator task is typically marked as "resolved" when the patch is merged, even though it hasn't been deployed to the Wikimedia wikis yet.

it's my opinion that both A and B have a bug because they're incompatible.

You're welcome to your opinion. Others need not agree. In this case, it's not merely "A is incompatible with B" because the problem only arises when someone writes wikitext that uses A and B together in a particular way.

Or, maybe they weren't known until this issue was opened.

That is, indeed, the case.

Because of inadequate testing, perhaps?

You're welcome to work on improving testing within MediaWiki.

With the kludges in place, how will the effects of the patch be tested?

Very easily. Most developers have one or more private installations of MediaWiki that they use for manually testing all sorts of things, and this bug is fairly easy to reproduce.