Indeed, MediaWiki API does not allow to extract a specified section of a specified WP article. And it would probably not be reasonable to process the whole WP article to extract the linked section.

The main issue with hashes in WP is that they are language-specific, whereas we support Wikidata items which links to the corresponding WP article for each language. For example, check https://musicbrainz.org/work/2fbaaf2d-deff-46fb-ac15-ac76e9e56eca/ and change MB UI language.

At best, we can stop displaying Wiki page intro when linked WP URL ends with an hash.

As for blocking anchors in WP URLs, it would be a STYLE (and then an MBS “URL cleanup”) issue.

The header is the abstract from the Wiki API, so I don't think it can be substituted by the anchor. That said, I'd support blocking anchor links.

"We don't really support linking to anchors"
IYO the bug is that you allow it
ie. the bug/fix is that MB should have rejected/needs to reject the addition of a subheadinged (anchored?) website address to this field.
This does not sound like an unreasonable viewpoint/change.

At present however it does allow this, so it should (and I would expect it to be a relatively simple bug fix) take you to the subheading (anchor).

IMO yes, Wikipedia (or, ideally, Wikidata) links should always be 1:1 matches

Is it preferred not to link to Wikipedia in these cases?

We don't really support linking to anchors - the pages linked should be specifically for the work (or artist, or whatever) in question.