Why is this "not expected"?

... in that example, you aren't using a wildcard, rendering the entire clause inapplicable.

The words "Needs at least "*"" appear to be entirely superfluous

Yes.

I knew that, but I thought I would start with the code patch, given that I have more experience with code patches that config patches.

Now comes the really long wait before my patch is reviewed.

I'd also recommend someone resolving the @todo I left in my patch (creating a custom icon instead of the default one) before this gets enabled.

Is this still relevant after T203941?

Sorry, forgot to claim this on Phabricator when I claimed it on GCI yesterday.

I note that this task exists on GCI, despite the Google Code In project having been removed. Is that an error?

<removed text from description that was true at the time, but is no longer true>

Does this message ever get shown when there is only one user being mentioned?

This won't be enabled until someone merges a config patch to enable it. When that is planned to happen I have no idea.

Do the two merged patches have to be from this year, or do merged patches from past years of google code in count?

The actual behavior I noticed and wrote a patch to fix was that the error message shows up twice if you use the same translation unit name three times in one page. It is possible that there is some other cause for this duplicate error message that I was unable to reproduce and this patch may not fix.

This feels like it was almost too easy for a GCI task, given how little time it took me to code.

(I've retokened and deprojected the task based on the assumption from your comment that this task is now being treated as the "add a new user right to allow this" case; I still feel that doing this without a user right needs consensus)

In T237268#5632444, @Aklapper wrote:

For example, imagine I want to find all of my contributions in which I've added "Hello" to the page's source.

Hi, what is the underlying use case for that?

In T229735#5601496, @Urbanecm wrote:

I would personally treat those namespaces as reserved for future use, which should contain 0 pages. By granting the rights we might make some wikis use the namespace for gadget description pages or anything like that.

The Gadget namespace already has pages in it. The argument that "the namespace has to be empty for technical reasons" has been unanimously rejected at RfD in 2017

In T229735#5597761, @MarcoAurelio wrote:

In T229735#5597311, @DannyS712 wrote:

So, to confirm, are there any issues with granting this to stewards and/or interface-admins?

If I understood @Krinkle right, this should not be done? What I don't understand is why we keep the Gadgets namespaces on Production if we cannot use them and we must not use them.

I believe bug was introduced by the fix to T234368.

If the request is reframed to add a user right to allow the deletion of pages that have always been redirects during page moves, regardless of target, then no I do not feel that needs consensus. I would even support the granting of that right to page movers. You would, however, need to retitle and redescribe the task accordingly.

The ability to move a page over a redirect that has multiple redirect revisions, all of which point to the same page, is a useful feature, which I don't expect to be controversial.

In T117736#5525814, @matmarex wrote:

Looks like the patches will be included in the next release, so they should be deployed to production wikis next week, 1-3 September.

In T226926#5404471, @Izno wrote:

I'd rather just see TEs get editcontentmodel tbh.

This is not a bug. The pages really are transcluding themselves, as a consequence of a recent change to the CS1 module system.

<removing link to topic on enwiki; the flow extension has since been uninstalled>