I would like to note that there are documentation systems that consist of linked PDF files. The extension of the function of Sumatra PDF that I have suggested is to be understood in this context.
With such a context in mind, I also believe that a separate browser mode really makes sense and is better than calling up the hyperlink with a key combination (as suggested above with Shift / Ctrl). For users in such a context, a browser mode would support intuitive navigation.

The good thing about Sumatra PDF is that the current version of the software already interprets relative hyperlinks in PDF files correctly and opens them in its own instance (and not in another program). I have tested various programs and with many this does not work at all.

Therefore, I believe that there are use cases where a "browser mode" for Sumatra PDF - discussed here within this thread - will really support users.

Hmm the Adobe forum comment about similar

the PDF/A standard recommends that conforming readers (such as Adobe Reader) not make hyperlinks actionable - which is why your hyperlinks don't work in PDF/A compliant documents.

That is only a recommendation but is based on security concerns.

Secondary issue when replacing window content is the need for a reverse action like go back.

Maybe I could do replace when SHIFT or CTRL is pressed when clicking on a link. But a separate mode would be too much.