Seems to be a re-edition of T350630, T296131, and especially T290194. This time, a simple example (reproducible locally) is http://localhost:8080/wiki/User:/Foo.

More broadly, I don't think /Foo should be considered a valid title when the namespace has subpages (like the User: namespace). And yet:

Title::newFromText( '/Foo' )->isValid(); // true, makes sense because subpages are disabled in the mainspace
Title::newFromText( 'User:/Foo' )->isValid(); // also true...?!

The second example is effectively trying to represent a subpage of an "empty" title. It's worth noting that empty titles are handled a bit inconsistently between page-related classes:

Title::newFromTextThrow( 'User:' ); // MediaWiki\Title\MalformedTitleException: The requested page title is empty or contains only a namespace prefix.
new PageIdentityValue( 42, NS_MAIN, '', PageIdentityValue::LOCAL ); // Wikimedia\Assert\ParameterAssertionException: Bad value for parameter $dbKey: must not be empty
$tv = new TitleValue( NS_MAIN, '' ); // No problem.
$t = Title::newFromLink_target( $tv ); // Also no problem!
$t->isValid(); // false, thankfully
Title::makeTitle( NS_MAIN, '' )->isValid(); // Also false

Despite the underlying problem being the same (trying to represent an "empty" page), I guess it would make sense to treat the subpage version differently than the special case of "the whole thing is empty". So presumably just add a check to splitTitleString?

EDIT: To clarify, the check I'm talking about is something along the lines of: if the namespace has subpages enabled, extract a list of pages from it, and make sure each one of them is valid (perhaps we can simply make sure it isn't empty, without recursing).

In T381733#10389025, @Daimona wrote:

This time, a simple example (reproducible locally) is http://localhost:8080/wiki/User:/Foo.

It's not reproducible for me with that, see also https://en.wikipedia.beta.wmflabs.org/wiki/User:/Foo

This may also be related to T100782. Dot segments are supposed to be removed in URIs per RFC 3986, but the underscore prevents that here.

https://en.wikipedia.beta.wmflabs.org/wiki/User:/./Foo -> normalizes to https://en.wikipedia.beta.wmflabs.org/wiki/User:/Foo when dot segment is removed.

https://en.wikipedia.beta.wmflabs.org/wiki/User:/._/Foo does not normalize because UrlUtils::removeDotSegments follows RFC 3986.

In T381733#10392991, @Ammarpad wrote:

In T381733#10389025, @Daimona wrote:

This time, a simple example (reproducible locally) is http://localhost:8080/wiki/User:/Foo.

It's not reproducible for me with that, see also https://en.wikipedia.beta.wmflabs.org/wiki/User:/Foo

Uhhh I can't reproduce it either. I don't know why I said I could. Maybe I had messed up with my local environment. I can reproduce using http://localhost:8080/wiki/User:/._/Foo?useskin=minerva

It seems to crash in Vector 22 and Minerva, e.g. at https://tr.wikivoyage.org/wiki/Kullan%C4%B1c%C4%B1_mesaj:/._/Anerka.

It renders fine e.g. in Monobook via https://tr.wikivoyage.org/wiki/Kullan%C4%B1c%C4%B1_mesaj:/._/Anerka?useskin=monobook.

In T381733#10412574, @Krinkle wrote:

It renders fine e.g. in Monobook via https://tr.wikivoyage.org/wiki/Kullan%C4%B1c%C4%B1_mesaj:/._/Anerka?useskin=monobook.

It does not for me. I only see the exception, it's recorded here https://logstash.wikimedia.org/goto/dc1daf1cb0cefc74edafe27c716ac46a

In my local, WikiLove extension also fails next in line with the same error, if I hack-fix the error in Vector.

While Vector, Minerva, MonoBook, Wikiloves, and possibly others, can be individually fixed, it'll mean the actual problem in core still remains. If this is expected then the doc comment of makeTitleSafe() needs to be corrected and the asssertion should be reassessed.