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 only 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.