It's pretty easy to construct cases where it fails, but all such systems will fail either due to changes in content or changes in structure, and many will fail due to ambiguity as well. It's only really useful to compare how this might fare against other approaches. An example would be producing an XPath expression. Which may be more robust to ambiguity but weaker to structural changes.

This system will fail if the content is different enough that the target text is gone, which I believe is very reasonable. And while you could construct ambiguous text that couldn't be disambiguated by picking a larger string, in practice the value added with the complexity of trying to solve that problem is probably not very good. For the purpose of linking to sentences and paragraphs, this system seems sufficient and probably even better than many alternatives. I don't think many articles have a lot of repeating sentences.

Other use cases than linking to actual text would probably have their issues. Like, trying to link to a cell of a table would be quite problematic. That case may be better handled with something like an XPath expression, but in any case it's a fairly different use case imo.

All in all, my initial opinion is that this design is useful and easy to understand. It gives you the equivalent of Ctrl+F which is not bad.

(Disclosure: I work at Google, but this is the first I've heard of this and I don't work on Chrome.)

This misrepresents the comment you're replying to. The case I gave was "linking to a single word." Articles have a lot of repeating words.

I can see users highlighting and linking to a key word or two in the section they want to link to. This is going to result in a broken link if it's not unique. This is not an edge case. It's not even mentioned as a potential issue in the spec.

Should the browser at least warn that this is going to result in a broken link as the doc currently stands? Should it disable the feature until sufficiently unique text has been selected? Should it just silently let you copy a broken link and chalk it up to PEBKAC (which is what the spec seems to imply)?

Needs more thought IMHO.

I really don't understand what this brings to the table, besides making people upset.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Window/find

Re: making people upset. I mean, nearly anything will upset people. One way a search engine could incentivize people to add more usable fragment identifiers is by ranking pages with them higher, but I am certain many wouldn't be thrilled by that.

If this is implemented I don't think it will actually raise serious compatibility issues, and it's not a huge deal to remove it later, it should degrade softly.

Using indices alone would also work, but would be exceptionally prone to link rot as text changes, especially in the case of short (e.g. 1-word) selections.

Plus, you can always select more text.

Usually the same phrase is not repeated in the text if you select more than 1-2 words.