What did you expect to see?

Valid link to https://www.instagram.com/reneefrench named Renée French.

I would not expect to see that. It's a <pre> block containing the following text:

...
.caption _Gopher_ by [[https://www.instagram.com/reneefrench/][Renée French]]
...

It's just text. It happens to be in present format. But godoc can't know that it should parse the square brackets and text inside as a link.

The best it could do is link all of https://www.instagram.com/reneefrench/][Renée instead of just https://www.instagram.com/reneefrench/][Ren, but whether that's better or not needs to be determined.

Also see https://golang.org/pkg/go/doc/#ToHTML:

A span of indented lines is converted into a <pre> block, with the common indent prefix removed.

URLs in the comment text are converted into links; if the URL also appears in the words map, the link is taken from the map (if the corresponding map value is the empty string, the URL is not converted into a link).

I think this is working as intended (except perhaps the URL matching stopping at the accented letter).

CC @dsnet who has been looking at godoc links. But I tend to agree that this is working as intended.

The logic for URL detection is in go/doc.ToHTML. It uses a combination of regexps and special-case logic as a heuristic for what is a URL. In #5043, the logic was adjusted so that URLs can contain parenthesis. It was further adjusted in #18139 to include square brackets.

A reasonable adjustment to the URL heuristic is to forbid the URL from containing an closing parenthesis as the first parenthesis of that form.

Thus, http://example.com/some_resource[foo] is valid, but http://example.com/some_resource]blah is not valid.

Change https://golang.org/cl/94876 mentions this issue: go/doc: simplify and robustify link detection logic

An update on what I said earlier. ] is not one of the safe characters that can be included in a URL without encoding (according to https://www.ietf.org/rfc/rfc1738.txt). RFC 1738 says it must to be encoded. So, it should be safe to stop detecting a URL at ] and not consider it to be a part of the URL.

Following the same logic, I'm not sure if http://example.com/some_resource[foo] should be detected with the [foo] suffix. Perhaps it'd be better to stop before the first [? If that was a correctly encoded URL, wouldn't it be written as http://example.com/some_resource%5Bfoo%5D?