It's a custom namespace on the English Wikipedia, yes. I think that makes "Allow customizing who can move pages in a custom namespace" an accurate description of my feature request.

A problem my suggestion has in its current state is that MediaWiki:Scribunto-doc-page-header also appears in doc pages that don't exist. My proposal as suggested would add every possible title to the category, which would be pretty bad. For this reason I propose that the categorisation kicks in only when the page exists.

Stjn is right. The issue only affects the 2017 wikitext editor.

Ideally, this would apply to soft redirects as well, but that sounds difficult from a technical standpoint.

This issue is more general than just categories. It also makes it impossible to find all the templates that transclude a particular template as is discussed here. This is an issue that can potentially affect all XfD venues since it apples to every link that is between includeonly tags. An example of this is Template:Deleted template, currently at TfD, where WLH missed two of its uses that were between includeonly.

This also applies to desktop since someone might change the URL by hand to point to the lead as suggested in an English WP help page.

I checked a few more. The Japanese, Korean and Farsi WPs all have the gadget too. I stopped checking after that.

"Τορ" would be pronounced "Tor" in Greek. Just because the letters look similar does not mean they perform the same function. In any case that's irrelevant. I used Greek as an example because it's my native language. The Chinese WP also has the Gadget and no such argument can be made for their writing system. If you're still concerned, how about you ask those editors themselves. I think that their inclusion of the gadget in their WPs shows that your concerns are overblown.

The html does not say id="top" anywhere so #top is ignored.

Isn't even in the current default skin

This is false, I tested Vector2022 while logged out and the anchor is there. (EDIT: To add to this, I tested the example you provided as well and it scrolled up, so your own example debunks what you said)

Yes, I think that's mostly right. The gadget is completely irrelevant to this issue as it's not what's creating the edit button on mobile (afaict it has no effect on the mobile layout AT ALL). I only brought it up as an example of the correct behavior. Note that what you're describing also happens on desktop when you click on any other edit section link. The gadget is only emulating desktop's normal behavior.

However, this all seems to be something that your gadget is handling, not part of mobile.

In T362467#9711511, @Xaosflux wrote:

There is no actual section on the page called "top" - and no one else would be able to follow it using that link. However, this all seems to be something that your gadget is handling, not part of mobile. Have you checked with the gadget maintainers?

I've already specified above I'm referring to Mobile Web (EDIT:I did not actually, but I thought I did. I'm sorry about that) So, as you can see in this edit when editing a section, a link to that section is added to the beginning of the edit summary. However, when I edited the lead by using its dedicated button, no such link was added. Instead, no section was added at all as if I was using the "Edit full page" button (like I did here). Here's an example of an edit to the lead section on desktop (done with the gadget I mentioned above). As you can see, a section link to the "top" section is added, which when clicked takes you to the top of the page, aka the lead section.

The same thing also happens in the Windows version of Firefox (I tested 67.0.4) when using the mobile wikitext editor. Once again, Chrome is unaffected.

I don't remember the original description.