The link points to the correct place in theory, but the browser ends up elsewhere, presumably something to do with the huge size of the page. A bug/limitation in DiscussionTools?

Can you copy/paste the full email content? It looks like the link takes you directly to the ping comment, where you can reply, instead of the top of the thread (https://pt.wikipedia.org/wiki/Usu%C3%A1rio_Discuss%C3%A3o:DarwIn#Pergunta_de_IJuulia_(14h28min_de_28_de_outubro_de_2021)). I believe that's by design.

Also, the timestamps are IDs used to help locate where to take you on the page. So I think this task should probably be renamed to "Notification email takes me to wrong place on talk page", although I am not totally sure that it is doing that?

Or rename it to "people should not have extremely huge talk pages" :) The section link doesn't reliably work for me either.
In any case, this task doesn't really have anything to do with Notifications. Target URLs are set by the extensions implementing the various notification types.

It’s not even DiscussionTools’ fault: it works in safe mode (at least for me); in non-safe mode some site script dynamically loads CSS that makes the page grow slightly in length after the browser has calculated the jump position. On my screen, this slight growth is about 1%, which means that the reply moves down by approximately 6800 pixels, or 8.8 times my screen height… So the proper advice is “people should not have extremely huge talk pages, or if they have, at least their wikis should not dynamically load CSS affecting page length”.

The link is indeed changed by DiscussionTools (see T253082), but it should work (and works for me… most of the time).

I agree with everyone above saying that the real problem is the page being very long, causing it to take a long time to load, and causing its contents to move around as it's loading.

In T295300#7497609, @Tacsipacsi wrote:

in non-safe mode some site script dynamically loads CSS that makes the page grow slightly in length after the browser has calculated the jump position.

Pretty sure it's this one: https://pt.wikipedia.org/wiki/MediaWiki:Gadget-FeedbackHighlight.css. Maybe I can just fix that.

The gadget consists of two parts, JS and CSS:

FeedbackHighlight[ResourceLoader|default|type=general]|FeedbackHighlight.js|FeedbackHighlight.css

The CSS part adds some styling for talk pages, and the JS part makes it also treat some non-talk pages like talk pages (e.g. village pumps, etc.). This causes both the CSS and JS to be loaded late, after the page loads.

Instead, I'll split the gadget into two, CSS-only and JS-only, where the JS part depends on the CSS part. This will allow the CSS part to load earlier, and at least avoid the flashes on genuine talk pages. (It won't fix the non-talk pages, but such is life.)

This problem and the solution is documented here: https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(users)#Gadget_type.

I also considered implementing it all in CSS only, but that would require some crazy selectors (and I mean like 50 lines of selectors like [class*=" page-Wikipédia:Páginas_"] dl dl dl dl dl dl dl dl, …). I'm not sure what would be the performance effect of that, I don't really want to spend too much time investigating, and I don't want to make anything worse.

Done: https://pt.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&type=revision&diff=62448530&oldid=62336372&diffmode=source

The original link seems to work consistently for me now. Can you all check as well?

In T295300#7514776, @matmarex wrote:

The original link seems to work consistently for me now. Can you all check as well?

Same here. Thanks for the fix!