Yes, it will. But actually I still think that two arrowheads with hovertexts is the right thing. It would allow expanding the data one without expanding the target one. And it avoids establishing the (imho) pernicious precedent that a xxxadic input can have slots with unrelated meanings. Actually I have to admit there's something a little like that in the Colors and Crayons library, but only for lack of the min/default/max feature and the hovertext feature.
C'mon, Jens, you're not just insulting me, but also the users. I have only just now realized why this doesn't work:
(Never mind that you don't need the CALL in this simple case. I'm pretty sure I remember a user having this very problem of wanting to use a zero-slot JOIN to denote the empty string—precisely because an empty slot would have been substituted into—in a situation that did require a CALL.)
You're going to hate this idea, but I think zero-slot variadic inputs should "absorb" actual input values only if there are no visible slots in the entire expression. Maybe even limit it to cases where the block with the zero-slot variadic input is the entire expression. You'll hate it because it's a special case on top of a special case, but I think the resulting behavior would much better fit users' expectations, because in non-zero-slot situations we've taught them to count input slots with respect to the entire expression, not with respect to individual blocks within the expression. That entire-expression count should apply to zero-slot counts too. And yes, I agree that this is my fault for not thinking through all of the implications of the design. And I think I finally understand what Dan Ingalls meant (in that recorded lecture I used to play in 61A) by a syntax being "not well-founded."
By the way, one reason I find your polyadic/variadic distinction confusing is that in my mind "variadic" is a property of an input in the procedure's definition (a formal parameter), rather than of a slot in a particular calling expression. That's one reason I've not been understanding some of the explanations you consider obvious, e.g.,
This is meaningless if it's the formal parameter that's variadic. We should work out a vocabulary that lets us talk unambiguously about either context.
Huh? Oh, wait, what's a "multi-input slot"? Because in the cases
I don't see why one slot (not zero slots) is semantically different from two slots. Once the two-slot case gives an error message, we're no longer in the Scratch world of "no such thing as an error." And, I just noticed, the text of the error message has "input(s)," so it clearly anticipates applying to the one-slot case!