I think what they're talking about, and what you might be as well, is the "with inputs" text of CALL, RUN, and LAUNCH W/INPUTS that doesn't appear if you don't have them in the block.
That's another reason for variadic groups of inputs.
Was what you were talking about pretty much the [with inputs v] [] of the BYOB 3 RUN, LAUNCH, and CALL?
Wait, didn't you just ask that and didn't I just answer?
In BYOB 3 the "with inputs" is itself an input, but now it isn't.
Edit: This is what I mean:
BYOB 3:
Snap!:
Oh I see. I'd forgotten that!
I no longer remember exactly why we changed that interface in 4.0. I think at that time Jens was skeptical about the whole idea of dropdowns to change the behavior of primitives. (As opposed to dropdowns to change the target of a behavior, e.g., which sprite or which attribute.)
Since then, though he's gone all in on the idea, as in the LENGTH block that turns into half a dozen other blocks via its pulldown. CALL WITH INPUTS vs. CALL WITH INPUT LIST is less drastic a change than LENGTH vs. JSON! So maybe we should revisit that decision When Things Slow Down™.
We now have several ways to distinguish among alternatives in a family of related functions: the original way, to have separate blocks, e.g,. for +, –, etc.; to have a hidden RELABEL option, e.g., for MOD, MAX, MIN, etc.; and to have an explicit pulldown, e.g., for LENGTH, FLATTEN, COLUMNS, etc. I don't think we have any coherent policy about when to use which. The reasons are partly historical (i.e., how does Scratch do it?), partly aesthetic (is a pulldown ugly here?), and partly a sense of just how related or unrelated the functions are. In retrospect we probably should have chosen RELABEL for the LENGTH block, but that would have been less discoverable.
I guess I made you remember something.
Maybe because no-one would really want a [inputs v]/[input list v] dropdown on all blocks with variadic inputs. (Except for (list < >) , (() >), and |script variables ((a)) >|.)
Oh yeah, that sounds right. At first only primitives had variadic inputs, but pretty quickly we added them for custom blocks too, and that required a notation. The red halo around the arrowheads is my fault, btw.
I wonder if Jens had any idea what to use for that.
I think maybe using the arrowheads was his idea -- my contribution was turning the halo red to discourage people from using it accidentally.
...
so I came up with this reporter
To use it in a simple way - just fill the first slot with the optional parameters that you want to supply to one of of my options slots and it will simply return the list you supply it
Obviously not really useful 
But if you fill in the 2nd slot with a list of optional parameter names you can use it like this
And you get exactly the same result as before but you can use the names of the parameters and only pass in the ones you need.
This emulates other languages that allow for both positional and named arguments
And the result of using this inside of the costume reporter
It looks nicer if I use a color picker of course
And the relevant code inside my costume reporter now looks like this
So, until Snap! introduces varidic custom reporters, this is my workaround
Here is the code for my options helper is anyone wants to use it
<blocks app="Snap! 6, https://snap.berkeley.edu" version="1"><block-definition s="options %'options' using names %'names'" type="reporter" category="lists"><header></header><code></code><translations></translations><inputs><input type="%s"></input><input type="%l"></input></inputs><script><block s="doDeclareVariables"><list><l>output</l><l>item</l></list></block><block s="doIfElse"><block s="reportAnd"><block s="reportIsA"><block var="names"/><l><option>list</option></l></block><block s="reportGreaterThan"><block s="reportListAttribute"><l><option>length</option></l><block var="names"/></block><l>0</l></block></block><script><block s="doSetVar"><l>output</l><block s="reportMap"><block s="reifyReporter"><autolambda><block s="reportJoinWords"><list></list></block></autolambda><list><l>value</l></list></block><block var="names"/></block></block></script><script><block s="doReport"><block var="options"/></block></script></block><block s="doIf"><block s="reportAnd"><block s="reportIsA"><block var="options"/><l><option>list</option></l></block><block s="reportGreaterThan"><block s="reportListAttribute"><l><option>length</option></l><block var="names"/></block><l>0</l></block></block><script><block s="doFor"><l>i</l><l>1</l><block s="reportListAttribute"><l><option>length</option></l><block var="options"/></block><script><block s="doSetVar"><l>item</l><block s="reportListItem"><block var="i"/><block var="options"/></block></block><block s="doIfElse"><block s="reportAnd"><block s="reportIsA"><block var="item"/><l><option>list</option></l></block><block s="reportListContainsItem"><block var="names"/><block s="reportListItem"><l>1</l><block var="item"/></block></block></block><script><block s="doReplaceInList"><block s="reportListIndex"><block s="reportListItem"><l>1</l><block var="item"/></block><block var="names"/></block><block var="output"/><block s="reportListItem"><l>2</l><block var="item"/></block></block></script><script><block s="doIf"><block s="reportNotEquals"><block var="item"/><l></l></block><script><block s="doReplaceInList"><block var="i"/><block var="output"/><block var="item"/></block></script></block></script></block></script></block><block s="doReport"><block var="output"/></block></script></block><block s="doReport"><l></l></block></script></block-definition></blocks>
We have variadic custom reporters; it's grouped inputs we don't have.
But your solution is fine; I used to do something like that in Logo. The only improvement I'd suggest is that your "names" list should actually look like the same kind of name-value association list you use for "options," with the values serving as default values for inputs the user doesn't supply.
Sorry for using wrong words 
[edit - I've understood what you mean now. I've been umming and rrring as to whether to supply defaults with the options helper or whether to let the code within the main custom reporter decide what to do. At the moment, I'm on the side of getting the main reporter to do that but I might change my mind) ]
Is this to make a list the same length as (names) but filled with empty items?
Yes
.....
Oh. That's exactly what it does. I thought you could leave out the (join >), but then I get this:
BTW I did that on (numbers from (1) to (10)).
Brilliant enhancement
For others - Dardoro is suggesting making a simple extra helper reporter for each custom block that needs variable options like this
This is the one I made for this
I gave it that long unique name so that it won't namespace clash if I use other ones in a project at the same time (See corrected version later)
Love it
Do you mean the "a" variables in these two?:
Because those won't clash.