Just saw this myself. Thanks for filing the bug.

Reverting the commit that @thomas-topway-it identified, fixes the problem.

I am affected by this issue in SMW 4.0.2 (2022-03-24).

@thomas-topway-it has dug deep into this one. However, I think it needs manual testing. @turnstyyle - can you test and tell us if everything is working fine.
Also the PR #5396 needs reviewing. Might be something for @hexmode ?

The changes in #5396 (8f6a918) fix the biggest problem for me. After the change, clicking a link from a URL property whose value contains a space character goes to the right place.

I noticed one more minor problem that may be related. URL properties whose value contains underscores render on the screen (i.e., when the property is set inline, or in contexts like Special:Browse) with the underscores changed to spaces. The link still goes to the right place (to the URL with underscores). For me, this is OK as long as the links work. This was also the case before #5396, and might be considered a separate issue.

In summary, this is what I see before the changes of #5396:

And this is what I see after #5396:

Thank you for testing!

@turnstyyle so the second url in the second column theoretically should and could be
https://example.com/one_two (with underscore) -- what do you think ? It depends on this code

		if ( $this->m_mode !== SMW_URI_MODE_EMAIL && $linker !== null &&
			// replace underscore with a space only for wiki links
			// either internal or external 
			// in all other cases a solution like the following
			// https://css-tricks.com/snippets/css/prevent-long-urls-from-breaking-out-of-container/
			// shall instead be used
			// @fixme the following method could lead to false-positives !
			Title::newFromURL( $url ) ) {
				$context = str_replace( '_', ' ', $context );
		}

I think the most correct is to remove the underscore also in captions for non-wiki url, as in the example. However currently the code, as you can see in the comment, can lead to "false-positive", I don't know if there are ways to achieve that which don't lead to "false-positive" cases.

@turnstyyle so the second url in the second column theoretically should and could be https://example.com/one_two (with underscore) -- what do you think ?

Yes, the fact that underscores in external URLs are rendered as spaces is unexpected and (in my opinion) undesirable.

It depends on this code

		if ( $this->m_mode !== SMW_URI_MODE_EMAIL && $linker !== null &&
			// replace underscore with a space only for wiki links
			// either internal or external 
			// in all other cases a solution like the following
			// https://css-tricks.com/snippets/css/prevent-long-urls-from-breaking-out-of-container/
			// shall instead be used
			// @fixme the following method could lead to false-positives !
			Title::newFromURL( $url ) ) {
				$context = str_replace( '_', ' ', $context );
		}

I think the most correct is to remove the underscore also in captions for non-wiki url, as in the example. However currently the code, as you can see in the comment, can lead to "false-positive", I don't know if there are ways to achieve that which don't lead to "false-positive" cases.

I don't understand what this code is trying to do. It looks like it wants to distinguish wiki links from other kinds of URLs? And relies on the Title::newFromURL method to do the distinguishing? I don't see how Title::newFromURL knows the difference between wiki links and other URLs—what's a URL that would be a true negative in that test?

If long URLs disturbing the layout is a concern, maybe CSS word-break will work.

hello @turnstyyle, yes, we could just remove the code supposed to identify an external wiki since it does not work, perhaps it was not the proper method.
Indeed, css' word-break or other directives should be always used without to change the semantic value of contents.
So this is the push request #5396

and it remains to address this #5396 (comment)

I had partially updated most of the tests, but because this is really tricky (mwjames created a lot of tests, with a content difficult to understand ) I think this should be supervised by at least another key-developer (otherwise a lot of work required to update all tests will be wasted)

perhaps my comment above contained an error

"I think the most correct is to remove the underscore "

should be

I think the most correct is to keep the underscore