I've just checked with a notification of an answer to one of my questions, and I see the same behaviour. If I am already at the URL for the answer (not the question) so that clicking the notification link does not change the URL, then it scrolls the window to the answer but leaves the notification panel open.

Scrolling back to the top is no longer necessary since "Clicking outside of notification popup does not close it" was fixed, but I still consider this a bug, just a less inconvenient one now.

Oh! I think I know why I thought it was fixed. I went to a question URL where I had a notification about an answer, and clicking that notification dismissed the notification pane. Are you saying that the bug only occurs where there is an exact match of URL -- comment thread URL, question URL where the notification is from the question itself, answer URL if it's from an answer?

Yes exactly! This is due to the way our answer URLs work. Currently a question is:

meta.codidact.com/posts/Q_ID

An answer is the same, but with the answer id added on the end (followed by a # to tell the browser where to scroll the page):

meta.codidact.com/posts/Q_ID/A_ID#answer-A_ID

The bit after # can be changed without a page reload (so you can follow internal links around a page without delay). However, including the answer id before the # means that this is a different URL (not just an internal link to a different location on the same URL). This forces the browser to reload. If we didn't do this the browser could just scroll rather than reload.

Although this would be smoother, it would no longer display the answer out of sorted order, with a message informing the user of this. Maybe in future we'll do this on the client side and remove the need for the reload, but I guess we should focus on the essential changes before this kind of fine tuning.

(For now all we need is a line of code to close the notification panel before following the link, so it won't matter whether there is a page reload or not.)