It doesn't:

$ curl -s 'https://en.wikipedia.org/wiki/Nights:_Journey_of_Dreams' | ack -o '<[^<]*cite_note-FOOTNOTESega20074.{1,9}5-8[^>]*>'
<a href="#cite_note-FOOTNOTESega20074–5-8">
<li id="cite_note-FOOTNOTESega20074–5-8">
$ curl -s 'https://en.wikipedia.org/api/rest_v1/page/html/Nights:_Journey_of_Dreams' | ack -o '<[^<]*cite_note-FOOTNOTESega20074.{1,9}5-8[^>]*>'
<a href="./Nights:_Journey_of_Dreams#cite_note-FOOTNOTESega20074–5-8" style="counter-reset: mw-Ref 7;">
<li about="#cite_note-FOOTNOTESega20074–5-8" id="cite_note-FOOTNOTESega20074–5-8">
<span id="mw-reference-text-cite_note-FOOTNOTESega20074–5-8" class="mw-reference-text">

Might have something to do with the JS library you are doing. According to the spec the anchor should be percent-encoded when parsing the URL, so maybe the library automatically does that for you.

@Tgr hmm the snippets I posted were from viewing source on https://en.m.wikipedia.org/wiki/Nights:_Journey_of_Dreams

You are right, the mobile version does have percent-encoded anchors (although in general the DOM viewer in the browser is not a reliable way of making sure - it shows the source after it has been corrected for various HTML parsing errors).

$ curl -s 'https://en.m.wikipedia.org/wiki/Nights:_Journey_of_Dreams' | ack -o '<[^<]*cite_note-FOOTNOTESega20074.{1,9}5-8[^>]*>'
<a href="#cite_note-FOOTNOTESega20074%E2%80%935-8">
<li id="cite_note-FOOTNOTESega20074–5-8">

Probably caused by the DOMDocument processing in MobileFrontend then?

This issue is tricky to debug and seems related to the HtmlFormatter library but is also causing T18854

Sadly this is not easily fixable (see https://phabricator.wikimedia.org/T188547#4063268)
You'll need to update this in the client. We'll be doing the same in MobileFrontend.

Potentially you might be equipped to fix this in the REST base layer.

So is this something we should address in the PCS @bearND

@Fjalapeno Searching for FOOTNOTESega20074 in the Parsoid version or the local PCS read-html endpoint (draft version) I see no percent encoding used in this href or id value. So I don't expect PCS to have this problem since it uses Parsoid.
FWIW, the new references endpoint looks clean in that regard, too. I checked even though the issue was really with the link from the content to the reference.
The only place I see this encoding is in the action=mobileview output the iOS app still uses.