I have updated the task decription according to my experience. In case of being unable to reproduce the bug, please see the previous version of the description.

Everytime I switch the editing mode, I get the missing edit summary warning upon clicking Publish, even though I provided the summary before the switch. It is quite annoying and what is worse, it teaches me to ingore the warning.

Currently the backlink is a static text. That means that the issue cannot be solved with styling. The easiest fix would be to output numbers instead of letters for backlinks in groups like lower-alpha.

Some observations: If the wikitext is slightly modified, the problem will go away:

After seeing the new proposals I changed my order of preference a bit:

This bug is quite annoying for Lua wrapper templates, because they inevitably use nesting. I will be very pleased if this gets fixed.

T202190 is probably the same issue.

CSS selectors like q:lang(cs) should be added as well, I think.

(Obsoleted by T171581#4568792)
My favorites in the order of preference (best first):

1. parent
2. refines (definitely with -s to indicate direction)
3. extends (definitely with -s to indicate direction)

Maybe this advantage has been mentioned as SEO already, but stating it explicitly:
Machine-understanding of HTTP redirects does not require any advanced parsing.

It seems that even some usage is tracked, although I am not sure if it is 100% correct: Employment of the new function leads to the following text appearing in the Edit source page:

Wikidata entities used in this page

• United States of America: Title

mw.wikibase.getEntityIdForTitle( pageTitle ) seems to work as expected at testwiki:Template talk:Country ID.

In T53736#3380437, @Krinkle wrote:

So perhaps it's better if we link to /w/index.php?title=Target&rdfrom=Redirect#Section.

In T53736#3380929, @Tbayer wrote:

Naive question: What would the analytics impact of this be - would we continue to register a webrequest / pageview for the redirect page, or would this change to the target page? (Cf. T121912)

@Krinkle Thank you for your thorough explanation. I just thought that the rdfrom parameter's purpose was to be able to provide the "Redirected from .." message while using a HTTP 302 redirect:
If /wiki/Redirect responds with something like
302 Found; Location: /wiki/Target?rdfrom=Redirect#Section, we will:

• not need to purge /wiki/Redirect upon modification of Target,
• not need to alter <a href="/wiki/Redirect"> in rendered pages,
• not need to purge pages linking to Redirect upon its modification,
• have to purge /wiki/Target?rdfrom=anything upon modification of Target.

In T53736#3349657, @GWicke wrote:

I guess cookie, localstorage, or magic URL parameter in redirect target (stripped in Varnish) could work, with different pros & cons.

In T151301#3377587, @thiemowmde wrote:

Note that follow="…" does not end with an "s". Should we stick to this and change the proposed extends="…" to extend="…"?

In T168770#3377433, @Fomafix wrote:

A better indicator would be to add cursor: pointer only when the JavaScript handler is attached.

In T168770#3377433, @Fomafix wrote:

A better indicator would be to add cursor: pointer only when the JavaScript handler is attached.

Change 267648 is a similar fix of the same bug (by @Fomafix):
[mediawiki/extensions/CategoryTree@master] Hide toggle buttons via CSS for clients without JavaScript

Among other things, I have inserted the words ", unless <ref name="A"> info2 </ref> exists as well" into the task description. If I got the consensual intention wrong, please correct it.

But it would be nice to display the disc-style list (the same as for the listing of pages in the category) until the JavaScript is available. This can be achieved by using JavaScript to just add a class to #mw-subcategories and doing everything else in CSS.

I can see that the span.CategoryTreeToggle is present in the HTML, but with style="display: none;". JavaScript changes this to "display: inline;". A simple solution will be doing the same with span.CategoryTreeEmptyBullet.

Still inconsistent in MW version 1.30.0-wmf.6 (rMW85da774930a7).

I have removed the sentence about performance issues from the description. It seemed to imply that this enhancement is not going to happen, but in fact it is just a problem that has to be solved as part of this task. Some of you already dipped in it above.

In T151305#2813932, @Jan_Dittrich wrote:

Is there any mechanism to show error messages? As far as I am concerned, if you do an edit and save it you are directed to the view of the rendered text again.

Performance is not a concern, because HTTP redirect to a fragment is faster than jump to an anchor using JavaScript (compare opening WP:Notability#General_notability_guideline and Wikipedia:GNG).

In T53736#3343170, @Krinkle wrote:

• In the Parser, when linking to a page that is a redirect, fetch the destination but only use its anchor (hash fragment).

In T144781#3339083, @Lahwaacz wrote:

It's well known that the URL fragment (the part after the #) is not sent to the server.

This problem can be fixed easily. Here is a dysfunctional (as Lahwaacz pointed out below) solution based on @TheDJ's proposal: If request_URI targets a redirect to Section and request_URI does not contain any fragment part then respond with a HTTP redirect to canonical_URI#Section. Otherwise respond like MediaWiki always did.

For the sake of naming consistency, maybe the new function's name should be mw.wikibase.getEntityIdForSitelink because we already have functions mw.wikibase.sitelink and mw.wikibase.entity:getSitelink. The latter has an optional parameter globalSiteId with values like "enwiki".

@matej_suchanek pointed out during the review, that mw.wikibase.getEntityIdForTitle(pageTitle) should add an entry to pagelinks, i.e. (if I am correct) record the target page as linked from current page, and I think that he is right. However, I believe it is ok to proceed without that now and leave it for the "improvements in the future", as @Tpt said. In majority of cases, the target page will be linked by other means anyway. For example, a flag template, which uses property P41 (flag image), will create a clickable link to the article about the country.
Note that this has nothing to do with usage tracking (T142093).

Someone please review @Tpt's patch mentioned in T74815#3314217. The most important functionality is already there and we have been waiting for it for years. That part of API is not going to be affected by the discussion of the final API.

In T74815#3314217, @Tpt wrote:

Some questions remain :

Setting the highest priority to hasten the investigation, which is possible probably only until the article is touched.

Apparently the bug was introduced by rEPIM195615137e99 (https://gerrit.wikimedia.org/r/139276/).