Here's a global search for __NEWSECTIONLINK__ in the main namespace: https://global-search.toolforge.org/?q=__NEWSECTIONLINK__&namespaces=0&title=

On a few wikis this is deliberate (meta, mw.org), but in most places it is accidental.

In T331635#8680952, @Esanders wrote:

[…] it appears that __NEWSECTIONLINK__ gets added to articles sometimes
(14 instances on enwiki: https://en.wikipedia.org/w/index.php?search=insource%3A%2F__NEWSECTIONLINK__%2F&title=Special:Search&ns0=1&searchToken=1rniex0x6adcivi9qkhjployw )
...presumably accidentally […]

In T331635#8680639, @Tacsipacsi wrote:

By the way, maybe it’s a good idea to add a tracking category to pages using __NEWSECTIONLINK__ in namespaces not in $wgExtraSignatureNamespaces so that editors can easily notice them. And to rethink the VisualEditor UX, as 15 out of these 16 enwiki pages got their __NEWSECTIONLINK__s in VisualEditor edits.

In T331635#8680952, @Esanders wrote:

In T331635#8680639, @Tacsipacsi wrote:

By the way, maybe it’s a good idea to add a tracking category to pages using __NEWSECTIONLINK__ in namespaces not in $wgExtraSignatureNamespaces so that editors can easily notice them. And to rethink the VisualEditor UX, as 15 out of these 16 enwiki pages got their __NEWSECTIONLINK__s in VisualEditor edits.

I think the UI is pretty clearly labelled. 16 mistakes out of millions of articles and hundreds of millions of edits is not a bad failure rate. en.wiki could probably fix this with an abuse filter

In T331635#8680982, @Esanders wrote:

In T331635#8680952, @Esanders wrote:

In T331635#8680639, @Tacsipacsi wrote:

By the way, maybe it’s a good idea to add a tracking category to pages using __NEWSECTIONLINK__ in namespaces not in $wgExtraSignatureNamespaces so that editors can easily notice them. And to rethink the VisualEditor UX, as 15 out of these 16 enwiki pages got their __NEWSECTIONLINK__s in VisualEditor edits.

I think the UI is pretty clearly labelled. 16 mistakes out of millions of articles and hundreds of millions of edits is not a bad failure rate. en.wiki could probably fix this with an abuse filter

I've removed these markers. I noticed a few __INDEX__ tags too, and there are 52 others: https://en.wikipedia.org/w/index.php?search=insource%3A%2F__INDEX__%2F&title=Special:Search&profile=advanced&fulltext=1&ns0=1

In T331635#8681161, @Tacsipacsi wrote:

In T331635#8680952, @Esanders wrote:

I think the UI is pretty clearly labelled.

I don’t think so. These are the exact copies on enwiki:

• Label: Show a tab on this page to add a new section
• Help text: You can force the display of an extra tab besides the "Edit source" tab on this page which will make it easy to add a new section, or force it to not appear if it otherwise would.

Neither of these mention talk pages at all (not to mention that the DiscussionTools terminology is consistently “topics”, not “sections”, so if this thing uses “section”, one can even assume that it’s specifically designed to be used on non-discussion pages).

16 mistakes out of millions of articles and hundreds of millions of edits is not a bad failure rate.

This measurement doesn’t prove anything, and you’ve also demonstrated why: it ignores articles volunteers (or, in your case, staff) have already invested time to fix. There can be 15 articles with __NEWSECTIONLINK__ because the switch is inserted in only 1.5 articles a year in average since VisualEditor’s initial deployment in 2012, but also because it’s inserted in hundreds of articles a day, but almost all are quickly fixed, only a few slip through. Probably the first case is nearer to the reality, but it certainly is not the reality.

en.wiki could probably fix this with an abuse filter

AbuseFilter is not for fixing software/UX bugs. First because if there’s a bug in the software, the software should be fixed, second because it’s not cross-wiki. Who will add the abuse filter on huwiktionary, where there are exactly zero admins who did anything in the last thirty days?

@Esanders Thanks for creating a more useful description than just pasting our previous conversation! However, I think the Page settings vs Advanced settings distinction is a bit wider scope than what this task should ideally have – so wide that I’d say T333165 is a subtask/duplicate in this wider scope.

Side note: French wikipedia community would like to have these settings not shown on articles (ns0). The addition of INDEX and similar magicwords is currently blocked on this wiki by an abuse filter. Majority of users don't understand why the whole edit is blocked because they hit an obscure button that is actionable, but that they should not touch :)

Related task: T110329