I am terribly sorry for the delayed response!

In T406415#11243999, @Alien333 wrote:

…
One possibility: we have this summer deployed Anubis to fight the bot traffic (T400229); during which work our routing setup has changed a bit, which could perhaps have changed our behaviour regarding escaped characters. (@MusikAnimal probably knows more about this.)

You'd be right! Indeed, this was due to an Apache misconfiguration when I rebuilt the VMs for the Anubis deployment (T400229). I have fixed this and have updated the docs accordingly.

Note XTools also accepts query strings, but will redirect i.e. https://xtools.wmcloud.org/globalcontribs?username=127.0.0.1%2F32 → /globalcontribs/ipr-127.0.0.1/32

A technical explanation, for the curious:

• GUC takes its arguments from a query string. Forward-slashes (/) for a value passed in must always be percent-encoded here.
• XTools generates its links (with few exceptions) with arguments styled like REST API paths, where forward slashes (/) are the delimiter between arguments
• Namespace support came first, then we added proper IP range support (T279041), which confused both Apache and the XTools router because of routes ending with /{user_or_ip_range}/{namespace}. I.e. is 127.0.0.1/32 the IP followed by the namespace ID, or just an IP range? (32 being an invalid MW Core namespace ID is incidental, we can't assume that)
• For Apache, we needed the AllowEncodedSlashes directive, in XTools, we added the ipr- prefix to distinguish IP ranges from namespace path arguments

Again, my apologies for the inconvenience :(