It's worth noting that Submodules don't typically provide anything but a URL to the Git repository. This URL isn't accessible to web browsers, so showing it as a real browser link will probably also frustrate people ("why did you trick me into clicking a link that just gives me errors?!"). Also worth noting that the Git URL is available on hover of the contentId of the submodule - so you can access it from the web if you really want to (though it's arguably a bit hidden).
We check the submodule URLs, and if they are relative to the current repository or look like they are on the current BBS instance (absolute URL matches the Base URL), then we can generate the browser-accessible URL for the repo and render a link. We could potentially support URLs to applinked BBS instances, or make an attempt to ping the URL and see if the response can be attributed to a well-known host, or special-case urls to bitbucket.org or github.com (UPDATE: actually we already do this!), but the cost/benefit ratio seems high for that. We'll most likely focus instead on shipping other features that'll benefit a greater number of customers.
If you change your base URL and use an absolute URL for the submodule, BBS doesn't know that the URL points back to itself (and actually, that URL will be wrong now - it won't work in a Git client either).
I'm going to make some minor changes to improve the title on the submodule when it's unlinked, but I'm not sure there's much more we'll do. If you have specific input, please let me know ASAP while I'm looking at this.
Cheers,
Adam
Ah I just realized that the initial issue talks about setting an SSH Base URL that is different than the web base URL. That is an interesting one - we might be able to fix that. As a workaround, you can still use relative links if that fits your use case.