Thanks for filing this @Spage, its been on my mind for a while. In hopes of T65792 to resolve I never thought of alternative solutions like these.

We bold the title of the page if it appears in the text. One option could be to prepend the title to the excerpt if no matches were found. @Vibhabamba, does that sound like an alright idea?

@Prtksxna This Flock > Hefted case is one where the word points to a disambiguation page.
Do we think that prepending the word will solve the problem. And would it be worth it?

For instance:

Even if we prepended Flock before Herd, would it inform the user that
the Flock article leads to Herd.

In T102280#1405330, @Vibhabamba wrote:

@Prtksxna This Flock > Hefted case is one where the word points to a disambiguation page.

You are right, prepending the title in that case wont' be useful, but, I don't think you followed @Spage's instructions.

@Spage wants us to hover over hefted and not flock, in the same paragraph. That page links to a Glossary of sheep husbandry, and the hovercard for it looks like this —

Screenshot of how Navigation Popups gadget handles this case:

This is not an "edge case", it's how millions of links are done, and the hovercards can be at least frustrating and often very confusing as a result. The OP's case is a good one, and I encounter the same problem all the time.

For glossary articles, I made a partial workaround, https://en.wikipedia.org/wiki/Template:Glossary_link (it gives a tooltiip message like "See '[entry name]' in [Glossary name]" indicating where the link goes). This works whether you use hovercards or not. See https://en.wikipedia.org/wiki/Nine-ball#Play and hover over "cue ball" in the second sentence of that section for a demo. But it doesn't do anything for articles in general. The problem reported here is also illustrated very clearly in the first sentence of the same Nine-ball article section; there's a link to the Billiard_table article and a "pocket" link immediately after it which goes to a subsection of that article, but the hovercard shows the same thing in both cases.

Since a regular Web browser places the viewport with the line containing the id anchor (or an old-school <a name=...> anchor) at the top of the viewpoint (at least if there is more than a screenful of content below the anchor), the expected and reader-practical behavior would be for hovercards to do the analogous thing, and extract content from that line downward.

Okay, @SMcCandlish point taken. Edge case was probably not the right phrase. I have definitely seen these cases, and I understand the bug, but if we were to count all the links that this impacts, I'm guessing it would be less than 10% of all links so that's why I'm advising a lack of focus right now until we've shipped a first version.

That said it is technically much more complicated (not impossible but complicated) to provide a summary based on a hash fragment right now as we need to work out how to extract that efficiently and provide space to store and address those via an API. Providing an API that works to the level of traffic will take some time and people which we don't have right now. That's why this is low priority.

FYI, this task was independently raised as a suggestion at the English Wikipedia Village Pump.