It currently supports forwarding regular query parameters (since T258444 was fixed), but it’s not clear to me when this feature is actually used (@Legoktm or @Nintendofan885 may be able to explain). If you put a link like [[toolforge:foo?bar]] into wikitext, it will generate a link with a URL-encoded ?, & and =.

I now understand when this is used: there are many, many places on-wiki that generate external links to iw.toolforge.org, using something like [{{fullurl:toolforge:guc|user=Example}} global contribs]. (Truth be told, most of them use “toollabs” as the prefix rather than “toolforge”, but tomato tomato.) IMHO there are several better options for such links:

• For very widely used tools, a dedicated interwiki prefix could be introduced to make internal links like e.g. [[globalcontribs:Example]] work. (Only works if there aren’t several variable query parameters.)
• More generally, I still think it would be nice to have this task if possible, so that e.g. [[toolforge:guc?user=Example]] works.
• But in the meantime, I think it’s better to link to the URL directly (e.g. [https://guc.toolforge.org/?user=Example global contribs]), and I’ve been submitting some edit requests and making some edits in that direction.

But this definitely means we need to continue forwarding regular query parameters. I hope that doesn’t rule out also supporting URL-encoded parameters (I’m not sure).

As far as I understand it, implementing this behavior would basically make iw.toolforge the only interwiki target capable of accepting query strings. By that I mean that the lack of syntax to generate normal query string clauses without URL encoding is a feature/bug of MediaWiki's internal link syntax. If we implement special support for working around this feature/bug specifically for Toolforge how would any normal wiki editor find that out?

The far easier solution would be to just have the tool in question not use a query string for parameters, aka [[toolforge:scholia/Q1513315]], which is, AFAICT, what was implemented? Visiting https://iw.toolforge.org/scholia/Q1513315 works for me.

I think it's reasonable to ask for support for e.g. https://guc.toolforge.org/user/Example too.

Thanks @Legoktm - that seems to work for Scholia. However, it doesn't work for Resonator - try https://iw.toolforge.org/reasonator/Q1513315 vs. https://reasonator.toolforge.org/?q=Q1513315 . And then there are more complex cases like https://glamtools.toolforge.org/glamorgan.html?&category=South_Pole_Telescope&depth=1&month=last or https://wikishootme.toolforge.org/#q=Q1513315&main_commons_category=South_Pole_Telescope etc. (and other links at the bottom of https://commons.wikimedia.org/wiki/Category:South_Pole_Telescope - or the infobox in most commons categories).

Switching to path-based input is something that tool developers would need to support in each tool

In T345783#9333011, @Legoktm wrote:

Switching to path-based input is something that tool developers would need to support in each tool

That seems unlikely in practice. Have you tried getting Magnus to update something with his tools...? ;-)