So the request is for an extension then, as the module currently exists.

In T91478#12188120, @Pppery wrote:

@Bugreporter2 Please don't hijack tasks to turn them into something completely different from what the original author asked for.

In T122292#12188879, @TPI81AF wrote:

If it is obvious which code repository must be updated, could someone please direct me to it so that I may take a look?

They are not external bots, but rather internal bots, are they not? They are not human users, anyway.

This, from Special:Version is potentially confusing:

Let's not do workarounds. They introduce Technical-Debt and cause more work later.

leg-end pie.

In T375930#10185167, @Bugreporter wrote:

Potential solution: create a __NODISAMBIG__ magic word which can be included in these intentional redirects.

So idealy (sic) we should create all Foo（bar） to Foo_(bar) for every current and future title with disambiguator.

In T433215#12157450, @Pppery wrote:

Wasn't this fixed in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CiteThisPage/+/1088880

I think this can be merged to T10516: Magic word to exclude pages from Special: LonelyPages because that there will fix this here.

You mean librarize?

This is an old one!

There are already an existing way of excluding specific pages from special page reports that are better than hard-coding them into the special page code.

Searching for nothing takes you to [[Special:Search]].

If we choose to do this, it wouldn’t just apply to this page; it would need to be implemented across many other special pages as well. This isn’t an argument against doing it; it simply means that, if it IS done, it should be done consistently across most special pages.

The description CLEARLY explains why this is NOT a duplicate.

T432748: Insert space character after namespace+colon in canonical page names is NOT a duplicate of this bug. It is a completely different approach. This is extremely irresponsible, @Aklapper.

Sans serif and monospace are different categories of things and are not exclusive. A font can be both monospace and sans serif, it can be monospace and serif, or it can be variable‑width and either serif or sans serif — because serif vs sans serif describes letterform style, whilst monospace vs proportional describes spacing. They’re orthogonal axes, not mutually exclusive categories:

I don't think this will be necessary if T432748: Insert space character after namespace+colon in canonical page names is implemented instead.

And you complain that I submit trivial bug reports @Pppery 🙄

Doesn't this violate the pretence that is otherwise maintained that "we can't tell the difference between inoffensive SFW images and offensive NSFW images." It appears to be important to some in the community to maintain this fiction at all costs.

Is this not a duplicate of T426106: Image Editor for Commons now?

OK, so now T426317: Delete-redirect-and-move message should include the redirect's target has been fixed by @Pppery (thanks to him).

In T432346#12129963, @doctaxon wrote:

I'd like to reinforce the point already raised: what we are dealing with here is an information-technical string – a namespace prefix and a page title joined by a colon as a structural separator. This is not a sentence, not a natural-language phrase, and not subject to typographic conventions of any spoken language. A language-based adjustment of spacing around this separator is therefore not appropriate, regardless of what orthographic rules apply to colons in prose. The colon here is a technical delimiter, not a punctuation mark in the linguistic sense.

Given that, I would also gently note that there are many long-standing open tasks in Phabricator that affect far more editors and readers and are still waiting for attention. Investing engineering effort into something that is, at its core, a category error seems difficult to justify.