This reappeared as related to T358588 and maybe we should re-triage this as maintenance work for Content-Platform-Team .

Change #493116 abandoned by Subramanya Sastry:

[mediawiki/services/parsoid@master] Emit lint error when a page has duplicate HTML IDs

Reason:

No longer relevant -- partial patch and we are also in PHP land now.

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

Change #1073572 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/extensions/Linter@master] Add a "duplicate-ids" lint category

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

Change #1073574 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/services/parsoid@master] Lint duplicate ids

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

Change #1074253 had a related patch set uploaded (by C. Scott Ananian; author: Arlolra):

[mediawiki/extensions/Linter@wmf/1.43.0-wmf.23] Add a "duplicate-ids" lint category

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

Change #1073572 merged by jenkins-bot:

[mediawiki/extensions/Linter@master] Add a "duplicate-ids" lint category

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

Change #1074253 merged by jenkins-bot:

[mediawiki/extensions/Linter@wmf/1.43.0-wmf.23] Add a "duplicate-ids" lint category

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

Mentioned in SAL (#wikimedia-operations) [2024-09-19T20:45:58Z] <dreamyjazz@deploy1003> Started scap sync-world: Backport for [[gerrit:1073871|Re-order arguments to DataAccess::addTrackingCategory]], [[gerrit:1074253|Add a "duplicate-ids" lint category (T200517)]]

Mentioned in SAL (#wikimedia-operations) [2024-09-19T21:00:53Z] <dreamyjazz@deploy1003> dreamyjazz, cscott: Backport for [[gerrit:1073871|Re-order arguments to DataAccess::addTrackingCategory]], [[gerrit:1074253|Add a "duplicate-ids" lint category (T200517)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-09-19T21:15:19Z] <dreamyjazz@deploy1003> Finished scap sync-world: Backport for [[gerrit:1073871|Re-order arguments to DataAccess::addTrackingCategory]], [[gerrit:1074253|Add a "duplicate-ids" lint category (T200517)]] (duration: 29m 20s)

Change #1073574 merged by jenkins-bot:

[mediawiki/services/parsoid@master] Lint duplicate ids

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

Change #1075077 had a related patch set uploaded (by Subramanya Sastry; author: Subramanya Sastry):

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.20.0-a22

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

Change #1075077 merged by jenkins-bot:

[mediawiki/vendor@master] Bump wikimedia/parsoid to 0.20.0-a22

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

For some reason this new category is timing out for me on en.wp with 100k results. Other categories with more don't (such as misnested tags which has 300k). Is the category still filling, or is there something weird going on? (I can work around it by selecting a namespace in the URL, so it's not a critical problem, but not everyone is going to know that is viable.)

Separate comment: I think the name could use some adjustment. These aren't "Duplicate Ids" (see also https://en.wikipedia.org/wiki/Id,_ego_and_superego#Id ), they're (either) "duplicate IDs" or "duplicate id attributes". ("duplicate ids" is almost as bad as "duplicate Ids")

Can someone please perform the rest of the "add a new Linter condition" checklist before closing this ticket? The new condition needs to be added to the lists in which Linter errors appear, including the Page Information entry for each page, and the necessary documentation and help pages need to be completed.

Izno's comment is also correct; this problem does not relate to Freudian psychology. It's better to fix it now than to wait until reports and other systems depend on a suboptimal naming choice.

including the Page Information entry for each page

Do you have an example where it isn't showing up? It appears to be working here,
https://www.mediawiki.org/wiki/Extension:Scribunto?action=info#Lint_errors

Change #1076048 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/extensions/Linter@master] Change capitalization of duplicate IDs

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

I think the name could use some adjustment

There's a patch up and this edit was made.

Change #1076048 merged by jenkins-bot:

[mediawiki/extensions/Linter@master] Change capitalization of duplicate IDs

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

The new condition needs to be added to the lists in which Linter errors appear, ... , and the necessary documentation and help pages need to be completed.

These edits have been made,
https://www.mediawiki.org/w/index.php?title=Help%3ALint_errors%2Fduplicate-ids&diff=6772997&oldid=6772988
https://www.mediawiki.org/w/index.php?title=Help%3ALint_errors&diff=6772876&oldid=6616726

In T200517#10181767, @ABreault-WMF wrote:

including the Page Information entry for each page

Do you have an example where it isn't showing up? It appears to be working here,
https://www.mediawiki.org/wiki/Extension:Scribunto?action=info#Lint_errors

They just started showing up on en.WP between the time of my comment and right now. Thanks for the response.

In T200517#10181227, @Izno wrote:

For some reason this new category is timing out for me on en.wp with 100k results. Other categories with more don't (such as misnested tags which has 300k). Is the category still filling, or is there something weird going on? (I can work around it by selecting a namespace in the URL, so it's not a critical problem, but not everyone is going to know that is viable.)

Hmm, I imagine what's happening is that the linter_cat_page_position index isn't being used, instead the primary linter_id. Since this is a new category, all the linter_id for its errors will be the newest ones so quite a few rows will need to be scanned before returning the ~50 requested.

Adding a namespace probably forces linter_cat_namespace.

P70205#281191 kind of confirms that.

Doing,

SELECT page_id,page_namespace,page_title,page_is_redirect,page_is_new,page_latest,page_touched,page_len,page_content_model,page_namespace,page_title,linter_id,linter_params,linter_start,linter_end,linter_cat FROM `page` JOIN `linter` FORCE INDEX (linter_cat_page_position) ON ((page_id=linter_page)) WHERE linter_cat = 25 ORDER BY linter_id LIMIT 51;

Goes from,

51 rows in set (47.742 sec)

to,

51 rows in set (1.708 sec)

Change #1080845 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/extensions/Linter@master] [WIP] Force using an index when paging by category

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

Change #1080845 merged by jenkins-bot:

[mediawiki/extensions/Linter@master] Force the use of the category index when paging by category

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

On nl.wiktionary, this template generates the Lint error for duplicate IDs, even though it doesn't assign HTML IDs. Could this result from using the same subheadings within the template? If so, why should this be an error? HTML does not preclude using the same header several times.

In T200517#10785684, @MarcoSwart wrote:

On nl.wiktionary, this template generates the Lint error for duplicate IDs, even though it doesn't assign HTML IDs. Could this result from using the same subheadings within the template? If so, why should this be an error? HTML does not preclude using the same header several times.

Sorry for the late reply. A regression was introduced in T368722. A fix should be deployed next week in T393982

@MarcoSwart That fix was deployed. I purged a few pages that included the template and they no longer have duplicate id errors.

@SyntaxTerror could you provide an example of a false positive so we can understand better how to support you?

I think it would also be helpful to determine why the template in question (assuming it is a template) is adding id attributes. These are supposed to be unique by the HTML spec. Perhaps id is not the right attribute to generate, and these should either be removed or changed to something like data-mw-.., which don't have to be unique.

@MSantos On this article for example: https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:LintErrors&wpNamespaceRestrictions=0&titlesearch=Anastasie+%28all%C3%A9gorie%29&exactmatch=1

We are actually looking at solving part of the problem by removing the IDs that don't have author AND date, that will reduce greatly the number of false positives (cf. https://fr.wikipedia.org/wiki/Discussion_Projet:Correction_syntaxique#c-SyntaxTerror-20260413132900-Racconish-20260411170200 in French).

If I understand correctly, these IDs are used only with Harvard style refs, but these are very rarely used (at least on frwiki), so this lint error is useless on most articles.

I originally came here because we don't know how to solve the problem, meaning that it's rather MediaWiki that has to be corrected, not wikipedias.

@cscott There can be errors with the 'id' parameter of the templates sfn, harv and harvnb, for example if there is a ref that has an id corresponding to two sources (for instance, two books from the same author published on the same year), but as I said above, these templates are not used much (on frwiki: 4000 articles for harv, 71000 for harvnb and 81000 for sfn, on 2.7 million articles).
We have a gadget that detect these errors by the way: https://fr.wikipedia.org/wiki/Projet:Scripts_et_gadgets/Notices/refErrors

[EDIT] sorry, I didn't understand your message completely.
The thing is on frwiki, we have a parameter called id in our {{cite ...}} templates that correspond to ref on enwiki.
We have only 3 Harvard reference templates (harv, harvnb, and sfn), and they all have an id (= ref on enwiki) parameter that corresponds to the one in the {{cite ...}}} templates (which is not the case on enwiki equivalent templates).

@SyntaxTerror the problem is solved by either not generating id attributes at all, or by making sure that the id attributes are unique on the page. The HTML spec does not allow repeated id attribute values on the page, and Parsoid does remove them if it finds them (by generating a new id and replacing it in the duplicate) - because Parsoid relies on these IDs to associate data to the node.

Now, it turns out that there are a number of CSS/JS rules that do also rely on these ids. With the legacy parser, it does work even if they are duplicated (and the CSS rule, say, is applied to all the elements that have the ID); with Parsoid, we cannot support this, and duplicate ids must be avoided if we want to guarantee that id-based-selectors continue working as expected. This is the reason why we introduced this linter rule. These are not false positive: these are problems that we believe need to be solved on the corresponding page. It's true that this is far less an issue than a duplicate ID for a value that's used to handle layout (as we've also seen at the time on frwiki - https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Questions_techniques/semaine_18_2025#Compatibilit%C3%A9_des_pages_Projet:Accueil_et_Portail:Accueil_avec_Parsoid), but we have no way of distinguishing the ids that are actually useful (at the very least, we wouldn't be able to see client-side adjustments!) from the one that are not.

Note that, with Parsoid, any duplicated ID gets replaced on the final rendering of the page; consequently they are not usable for any goal that would rely on their presence/value. (Unique ids will be preserved, though.) With that in mind, suppressing the ID generation altogether (or, say, unless it's explicitly given as a parameter) on these templates may be something you'd want to consider. As @cscott says, if it makes sense to have that information somewhere, adding it to another attribute is probably the right move. In any case, we're happy to discuss your use case and to help find a solution (but removing the lint category is a priori not one of them.)

@ihurbain : can you explain me why there are so many errors, what is the real technical problem linked to these errors, and how to solve them easily, millions of times?

I am sorry, but my knowledge in HTML/CSS/JS is very limited, and I have trouble understanding technical English.

Also, note that I just discovered that enwiki and frwiki Harvard templates do not have the same parameters, so this adds to the problem (see my EDIT in the message above).

(english version below)

@SyntaxTerror je viens de regarder le contexte un peu plus large (désolée de ne pas avoir fait ça plus tôt) et je comprends mieux le problème que poserait toute correction "simple". Pour répondre à la question du nombre élevé d'erreurs :

• un seul identifiant peut être répété plusieurs fois, et cela va déclencher plusieurs erreurs; une seule page peut avoir plusieurs identifiants dupliqués et ça va également déclencher plusieurs erreurs
• le problème est beaucoup plus large que les éléments référencés par les références Harvard, et a typiquement le potentiel de toucher tous les modèles qui utilisent https://fr.wikipedia.org/wiki/Module:Biblio/Commun pour générer des ID.

Ceci étant dit : le problème n'est PAS intrinsèque aux paramètres "id" des modèles harv/harvnb/sfn. Ces modèles *utilisent* l'attribut ID qui est généré par les modèles de bibliographie.

Le modèle de bibliographie génère un truc du genre <span id="NomAnnée"></span>, qui est ensuite référencé par le modèle harv comme {{Harv|Nom|Année}} ou comme {{Harv|Nom|Année|id=NomAnnée}} pour pouvoir générer un lien qui renvoie vers l'ancre NomAnnée <a href="#NomAnnée">. Le problème est au niveau de la génération du span (et de son attribut id) PAS de son utilisation (même si l'utilisation fait appel à un paramètre id... qui ne se traduit pas par un attribut id en HTML). C'est parfaitement correct d'avoir par exemple {{Référence Harvard |Tremblay|Pignon|Dumouchel|1997}} plusieurs fois dans l'article (par exemple pour référencer plusieurs pages) ; avoir plusieurs fois {{Ouvrage|nom1=Tremblay|nom2=Pignon|nom3=Dumouchel|année=1997}}, même pour référencer plusieurs ouvrages, pose problème dans le cas actuel (c'est en particulier le cas du modèle Lien web qui n'a pas nécessairement d'auteur).

Modifier les identifiants générés va casser les liens existants vers ces ancres, ce qui n'est pas idéal. Ce que je ne sais pas, c'est "à quel point" ça va être pénible - comme vous avez des outils pour détecter les cas problématiques, il est largement possible que les pages sur lesquelles il y a un problème aient déjà une solution de contournement (par exemple en déclarant des id uniques dans le modèle de biblio) et que ça se passe assez bien. Pour répondre à cette question, ce que j'aurais tendance à faire serait d'écrire un script pour vérifier toutes les pages qui déclenchent ce linter, et de regarder sur la page s'il y a un lien vers cette ancre générée. Ça donnerait une idée de l'ampleur du problème et ça informerait la réponse à apporter.

I've had a look at the larger context (sorry I didn't do that before) and I now understand better what issues would be triggered by any "simple" solution. To answer your question about the large number of errors:

• a single identifier can be repeated multiple times, and that'll show as multiple errors; a single page can have multiple duplicated identifiers, and again that'll trigger multiple times for a page
• the issue is much larger than only the elements referenced by a Harvard reference, and can typically affect all templates using https://fr.wikipedia.org/wiki/Module:Biblio/Commun to generate IDs.

This being said: the problem is NOT specific to the "id" parameters of the harv/harvnb/sfn templates. These templates *use* the ID attribute that has been generated by the bibliography templates.

The bibliography template generates something like <span id="NameYear"></span>, which then gets referenced by the harv model as {{Harv|Name|Year}} ou comme {{Harv|Name|Year|id=NameYear}} to generate a link that points to the NameYear anchor <a href="#NameYear">. The problem is at the span generation level (and more specifically its id attribute), NOT its usage (even if the usage refers to a id parametar... that doesn't translate to an id attribute in HTML). It's perfectly fine to have, for instance, {{Référence Harvard |Tremblay|Pignon|Dumouchel|1997}} multiple times in the article (for instance, to refer to multiple pages); but {{Ouvrage|nom1=Tremblay|nom2=Pignon|nom3=Dumouchel|année=1997}} multiple times, even for different books, is the problem in the current case (especially for the Lien web template that doesn't necessarily have authors).

Modifying the generated identifiers is going to break existing links to these anchors, which is not ideal. What I do not know, is "how annoying" it's going to be - since you have tools to detect problematic cases, it's quite possible that pages on which the problem happens already has a workaround (for instance by declaring unique IDs in the bibliography template) and that everything works fine. To answer that question, I'd probably write a script to check all linter-triggering pages and check whether they do have links to the duplicated anchor (if yes, it needs to be modified; if not, it's probably not much of a problem to modify/drop the duplicated ID). It would give an idea about the size of the problem and it would inform how to proceed.

@ihurbain The only thing I want to know is why is this lint error detected, and what is it useful for?

@Izno talked about a discussion on enwiki without giving a link to it, and he says that he wants to fix duplicate IDs, but we don't know what for.
I would like to know if detecting this supposed error really helped him and what for.

It is always possible to detect something, but why doing so if it is useless ?

Anyway, having to look into millions of pages cannot be the solution.

I don’t really care whether this error is detected or not, but I try to sort out issues whenever I can on frwiki, and all these false positives are probably masking a real problem.

Perhaps there aren’t any true positives because the problem hasn’t been properly identified, and there’s another way to solve it that doesn’t involve checking every ID on every page.

By the way, we have a whole project on frwiki ( Projet:Restauration des ancres brisées/Références Harvard) that involves correcting around 20,000 articles with Harvard ref not working.
These errors can be detected without that 8 million pages list.

In T200517#11819750, @SyntaxTerror wrote:

@ihurbain The only thing I want to know is why is this lint error detected, and what is it useful for?

@Izno talked about a discussion on enwiki without giving a link to it, and he says that he wants to fix duplicate IDs, but we don't know what for.
I would like to know if detecting this supposed error really helped him and what for.

It is always possible to detect something, but why doing so if it is useless ?

Anyway, having to look into millions of pages cannot be the solution.

I don’t really care whether this error is detected or not, but I try to sort out issues whenever I can on frwiki, and all these false positives are probably masking a real problem.

Perhaps there aren’t any true positives because the problem hasn’t been properly identified, and there’s another way to solve it that doesn’t involve checking every ID on every page.

By the way, we have a whole project on frwiki ( Projet:Restauration des ancres brisées/Références Harvard) that involves correcting around 20,000 articles with Harvard ref not working.
These errors can be detected without that 8 million pages list.

As far as I know, the basic problem is that the HTML specification does not allow duplicate usage of the same id value on a single page, so the Wikimedia software detects an error.

On English Wikipedia, and probably on French as well, the duplicate id issue appears to come primarily from citation templates. Changing the way that citation templates behave may fix millions of errors without requiring editors to edit millions of pages. Because the citation templates create so much noise in the category, it will be best to resolve the citation template problems before trying to fix individual errors on other pages.

There will be thousands of non-citation duplicate id errors, for example an editor using "id=" in their signature and signing more than once on a page, but those will be 100 to 1000 times less common than errors generated by citation templates.

The lint error is detected when Parsoid sees that two different HTML elements are associated to the same id attribute. With the legacy parser, the "only" impact was that it made the page not HTML-spec compliant (although that's a minor issue), and that it could make things behave erratically - for instance, one could have links pointing to two different places, always go to the first one (depending on the browser implementation, I suppose), and that would be confusing.

On Parsoid, though, we do need the unique id to be enforced on the page, so we do drop the duplicates. The duplicates have normally been explicitly added to the page by editors (if they are not explicitly added, there is no id by default, and Parsoid adds one), so dropping them is something we DO want to signal somehow.

This does lead to issues, because sometimes things do depend on these explicit decisions - we've seen that a few times around layouts that would break badly with parsoid because the CSS putting them in shape was depending on ids that had disappeared - and that has been the main driver for this linter. We do believe that fixing wikitext that does end up generating duplicating ids is a good idea in any case, and in that sense we do not consider these to be false positives - Parsoid has to manipulate content that has been explicitly asked for by an editor; making noise about it is generally a good idea.

I do agree with @Jonesey95 that changing the way that citation templates work will help fix the issue, BUT I'm wary of the fact that these ids can be in use as well (and not easy to substitute for something else either) for links - I believe that this could add a lot of pages to Projet:Restauration des ancres brisées/Références Harvard, and I don't know how reasonable that would be to y'all. This is why I suggest trying to get an idea of the scope of the actual problem - i.e. "if the way ids are generated on bibliography templates were to change, how many internal links/how many pages would be impacted?"

I'm working with @SyntaxTerror on frwiki to try to solve the problem there.

The id generated by the cite templates are just a part of the problem, but not only (see for example template CatalogueofLife).
It seems the need is similar there : when a reference is defined by a template (either by a cite template or other templates like CatalogueofLife), the template generates an id based on the parameters so that it can easily be referenced from somewhere else in the article if they want (with a Harvard template for example).

So, most of the errors reported by the linter have currently no impact whatsoever on the articles because there are no reference to the id. But they mask the important errors, the ones where the change in behavior will break the articles.

I do believe that a solution that would make this part more difficult for contributors won't be accepted by the community.

For the cite template :

• If the id is created only if explicitly asked for (a parameter in the template): this would require a bot to edit many many articles to add this explicit request so that ids that are actually used are still visible (not very good), and it will require contributors to do more things when they want to link to a reference (so I don't think it would be accepted)
• If the id is created automatically also if it is used : this would be really nice, because it would solve most of the reported problems and will leave only the important ones to be fixed by editors or bots. But I don't see how it's possible to do that (in a template be aware of what's going outside of the template)
• If the id is created automatically unless it's explicitly denied (a parameter in the template) : a bot could go through the current errors and deny the creation of the id if it's not used (it would require many many modifications, since we have 8M errors reported). It would still need to be run on a regular basis. And it would make things more complex for adding links when the id automatic creation was denied.

For the moment, we're first trying to fix errors when the id is defined with only the year. As it doesn't seem to be a valid Harvard reference, and that it doesn't really work, we should be able to remove the automatic creation of the id when there's only the year.

After that, we're open to suggestion on how to fix the problems (without making things more difficult for contributors)

To be clear, the only thing I want to be changed is the way these errors are detected.

frwiki and enwiki are dealing with sfn/harv/harvnb/etc. templates differently: frwiki has id parameters (= ref on enwiki) in these templates linked to the same parameters in the bibliographic templates (fr:{{article}}/{{ouvrage}}/{{lien web}}/etc. en: {{cite ...}}/etc.).
After correcting Harvard refs, I discovered that enwiki method is probably better for maintenance, while frwiki method is easier for contributors, but leading to more errors and misuses of the Harvard templates (and some contributors do really crazy things with Harvard refs).
The thing is it would require to modify tens of thousands of articles and many templates to harmonise the two, so it is probably too late to do this, as the gain would be minimal.

Anyway, the current IDs should stay as they are, as they are not the problem (if two are identical and a Harvard ref is needed, a letter can be added to the year, as done in scientific papers, or the id/ref parameter can be used)
The real problem is the way these lint errors are detected, because millions of errors don't help to solve anything.

I don't have a solution to make the linter smarter / detect some issues and not others. What *could* be done would be to add filters on the Linter interface so that the lints generated by specific templates could be excluded (or specifically selected) from the table, to be able to focus on parts of the problem at a time. Would that help? (This wouldn't change anything on the detection/reporting, only on the reporting visualization.)

@ihurbain : I just came here to report a potential issue.
As far as I know, frwiki doesn’t use this Lint error-detection system, and I assume no other project does either (who would find a list of millions of errors useful without even knowing what the actual problem for the article is?).
If this system could detect errors that have a real impact on Wikipedia and its readers, it might be useful, but many articles that contain dozens of these so-called errors are perfectly fine.

I checked a few of the errors reported on frwiki, and I don't see any solution on wiki to fix them that wouldn't require both a huge amount of work to "fix" the current "problems" and adding unnecessary complexity in many use cases for regular editors.

What I see is that the vast majority of errors reported by the linter have no consequence at all on the page rendering, because most of the errors are about ids that are not used by anyone, just generated automatically in case someone needs them (to make it simple to link to an existing reference for example, instead of manually having to add an anchor before being able to link to it). It's the problem we saw with Harvard references templates. But it's not at all the only case, see for example the Bioref template.

Would it be possible to restrict the detection by the linter to ids that are actually used, instead of simply defined?

@NicoV the problem is that we do not a priori have a list of IDs that are "actually used" vs "simply defined". We can get that for the page itself, but it says nothing about the various CSS / templatestyles / gadgets that may depend on these IDs. One of the issues for which we've introduced this linter was the fact that generating multiple IDs of the same name on portal pages was breaking said portal pages - but those IDs were not used on the page itself, only on Common.css. And, ironically, these are the ones we'd actually be very interested in fixing :) (But, indeed, they are impossible to detect in the current state of things, which does defeat the purpose of that lint.)

That said: it is true that "multiple IDs where the ID is used as an anchor on the page" is a stronger lint category, which might be of use, and could probably be implemented.

Overall, I think the way forward is to find a way to disable ID generation unless it is asked explicitly (my impression is that many of these go through Biblio:Commun.spanInitial, and that's would probably handle a lot of cases). That's not something that can be done from one day to the next (because that would break a lot of links!), but that can be worked towards, I think. This would be something like:

• add a layer that asks for the ID explicitly; tweak the current modules so that it uses that parameter (but set it to true in the current version of the modules)
• migrate the pages that have an anchor to a link to this layer (either with a new parameter "ancre=auto" or with another layer of template, or something; it feels like it can be handled in a not-that-confusing way) - that wouldn't modify the current anchor or link, only the way it's generated, and that can probably be done with a bot/script
• drop the generation of ID by default (by setting the default version to false)

Later users that want to use the anchor do know that this is what they are doing (so adding a parameter is probably not a huge ordeal), and in that scenario, it would also detect conflicting ids that are actually intended to be used. Would that make sense?