Strange, I see only "Error" regardless of whether I'm logged in, or even if I switch to Chromium. There's nothing in the browser console that would indicate a client-side failure anyway.

Seems good now? I haven't noticed any problems with functions like Z26107 recently.

Made Z38229.

https://abstract-data.toolforge.org acts as a partial workaround, for links to WF from AW,

Still a problem; see https://www.wikifunctions.org/wiki/Z38095.

Further discussion at d:WD:Property proposal/Wikifunctions_object.

I've been replacing calls to Z6821 with Z30120 or other more granular functions, and there are now < 500 references on WF (mostly in tests) and < 50 on AW.

Still broken. I think the 2-ary ones mentioned in OP are still broken too, but it's hard to tell since they have multiple Implementations.

I'm seeing Z579 thrown, but it doesn't exist as a persistent Z50 yet, so there's just a cryptic message with a link to the main page.

Yes. I'm not super familiar with the code, but it looks like there are 3 toUpperCase calls in that file.

builtinEqualsWikidataClaim (Z6807) needs the same patch. See this test or this call.

I made Template:Link to source for builtin, just hardcoded.

While you're at it, could you remove the toUpperCase call? Z60K1 is limited to lowercase.

Forgot to reply, but yes, there was (at least) a second way it could break. I've been using the clipboard in the past few days without issue, and my original example works too.

There's no activity in NLG for Japanese at the moment, but I can raise this question at the first opportunity.

As workarounds, the lists f:Category:Functions with only code implementations and f:User:ExcarnateSojourner/Adding Python implementations (which includes JS) have been made.

I believe support for literal Z8s in the composition editor is the subject of T394458.

This can be implemented without hacks for arbitrarily large n (I assume there's a limit on code size for compositions, but I can't imagine a Function that would need dozens of distinct arguments).
Was it just this Implementation that was problematic, or is it all similar hacks using Z7/Function call?

How would one go about implementing swap then? I've tried this approach a couple times without success, and looking at the implementation for the K combinator is no help, because trying to enter a literal Z8 like it has there just summons a single, non-functional field.

Confirmed fixed!

Finally found the motivation to clean up my local changes to the Blockly prototype and push. (In the meantime, Google has transferred ownership of the library to Raspberry Pi.)
The main technical changes since April are the inclusion of the type checks I alluded to, and fixes to broken or incorrect serialisation. I also populated the toolbox with many list, bool, and number functions and wrote some usage instructions.
(see edits below)
I wouldn't say that makes it usable as an alternative editor or even a sandbox for compositions, but it does now look a lot more like what I'd envisioned. Here's a comparison of how a bunch of nested list operations is visualised in Blockly vs. the live Wikifunctions:

T341672 seems related.

If the only concern was running malicious user-submitted code, why do Tests execute for unconnected Implementations?

Also affects e.g. isiZulu.

Could not reproduce in FF 140, KDE Plasma 6.

Possibly related to T248634: Language list name sorting on mobile should not show names that start with latin characters with diacritics at the end?

mul-lang aliases are also not used as candidates for search/autocomplete. I think that would be the 80/20 for this feature.

Still present on e.g. https://www.wikifunctions.org/view/en/Z24659?success=true

Oh, I was just looking at that part in WF:Function_model today. Can the frontend use the list's "type argument" as a hint that it's a String and not a Reference?

I've made a prototype for how compositions could be represented and edited as blocks, using Blockly.
It doesn't pull any live data from Wikifunctions, but I've tried to have it export in the canonical JSON form, and maybe it can find a use just because of that. Blockly can accommodate simple type checks, so I think with a bit of effort I could make that work for the few included types—but the feeling I've gotten from trying to pull in plugin libraries is that there is only the illusion of plugin libraries, and further UI/UX improvements will likely require copy+pasting whole chunks of code and hammering them into shape. Which mirrors what @Feeglgeef told me on IRC.
All that said, I hope this prototype can at least convince more people that a block interface is a good idea, even if Blockly itself isn't used for the final product.