Moved to TextExtracts. FWIW, I remember discussions around similar things happening before (specifically, redlinks for sectionlinks that don't exist) and it was technically rather difficult to do.

Any update on this?

This also needs to work for links to #fragments defined in {{anchor}} templates.

When this is implemented the Hovercard popup should probably show the page title (T102280), because the section text will often only make sense in context ("After three years in that position, she joined IBM").

It would be hot if the hovercard, or a template-triggerable variant of it, could start showing content starting at the specific anchor used in the link. If this were combined with the ability to trigger it for links on the same page, not just to different pages, this would be insanely great for glossaries (see https://en.wikipedia.org/wiki/MOS:GLOSSARIES and Wiktionary has them, too). For an example, see https://en.wikipedia.org/wiki/Glossary_of_cue_sports_terms]]. The zillion intra-glossary links in that could just pop up the definition in question (as could similar glossary links at articles like https://en.wikipedia.org/wiki/Eight-ball that link to this glossary), instead of the current practices, which are just a tooltip saying what entry it goes to (generated by the https://en.wikipedia.org/wiki/Template:Glossary_link tag) and, in the present hovercard, the top of the glossary's article page, if you are on a different page than the glossary itself. Many articles have embedded glossaries, too; they're not all in separate articles.

Why is this set to "Low" priority? It's been my experience, with a large number of projects, that marking a report/request low-priority means it will most likely never be dealt with. Having the hovercard show the content that the link actually points to, and stop misleading readers, would appear to be a high-priority item.

It is low priority as other tasks on the Web-Team-Backlog plate are considered more urgent or more important.
Contributed patches for tasks that strongly interest you are always welcome!

I haven't figured out enough about this system yet (I've barely been able to get into it until recently due to LDAP issues with my account) to know where to start. I assume there's a git or svn repo somewhere. Anyway, not everyone who reports problems here is a programmer. The "this is going to remain on the back burner unless you code up a solution yourself" approach may make sense in, e.g., the GCC compiler development bug tracker over at GNU, but isn't very responsive when it comes to the issue tracker for a system that is mostly used by writers and readers of plain prose. Depending on what language this is written in, I might actually be competent to help, but the average Wikipedian (or user of other wikis) is probably not a coder.

My comments here have not been in the "wouldn't it be cool if [insert some obscure feature request here]" vein, but "I see this has been enabled on major projects like en.Wikipedia, but it is doing some very reader-confusing things." All four of these are problematic: 1) displaying the article lead when a section was linked to; 2) displaying nothing when the page has no lead; 3) displaying nothing for non-mainspace pages; 4) displaying the first image below an infobox instead of the one in the infobox). There are others, but these are the four really big issues that I have encountered with hovercards.

Note that there is a description of what to extract for specific use case in T156041: Page Previews should be able to show page fragments (sections of pages)