Why reinvent the wheel?

[drayzen]

All browsers already have the ability to find and/or highlight multiple iterations of a text phrase via their search functions.
Why not simply have the browser recognise the URL tag as a request for page search, using it's internal search function, with an iteration identifier?
e.g. #search=Phrase%to%find,3

The long phrase search would be more practical by simply adding a 'searchEnd' option that includes the iteration variable thus also enabling provision to allow for multiple iterations to be highlighted.
e.g. #search=Phrase%to%find,3,searchEnd=end%phrase.,3
or
#search=Phrase%to%find,3,searchEnd=end%phrase.,4

Possibly include a forced highlight option that overrides the browser's setting:
e.g. #search=Phrase%to%find,3,h

Far simpler, usable and easily memorable than all of that 'targetX' nonsense, and doesn't break if it's not the first iteration you want to link to.

I'm honestly surprised there's been coding time given to implement this using such easily broken methodology...

I'm sure there will be instances of conflicts with '#search', so have it substitute with '#search1' if a conflict arises.

As stated in other feedback, there is still the issue with page edits breaking links.
So while imperfect, a simple link to 'x% of page vertical pixels' may prove to be a more reliable solution.
e.g. #vertPct=42
A highlight option could be provided by specifying two percentages.
e.g. #vertPct=42,45

An included value for aspect ratio could be used to work around layout differences.
Certainly simpler to implement and continues to work at least with some degree of accuracy regardless of changes to the page content.

[dead-claudia]

Why not simply have the browser recognise the URL tag as a request for page search, using it's internal search function, with an iteration identifier?

The original proposal in spirit is basically this, just without the iteration identifier. 😉

[bokand]

As mentioned, the existing implementation is effectively leveraging the search function in Chrome.

I think the most promising idea for disambiguation is to add surrounding text as context as mentioned in #4 so I'm going so I'm going to close this in favor of that issue.

[will-ca]

Showing the browser search interface would help remove ambiguity about whether the highlighting is added by the linker or a part of the page itself (#109), as well as give the user a way to remove the highlighting if it's unwanted.