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:
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.
And I've included a dummy reference to it inside my costume reporter so that it gets bundled into the main reporter export
Yes - that was the idea to have differenet variable name but I see if doesn't work 
I'll have to see if adding in some invisible text will get around the issue...
It needs different title text, or a different number or placement of inputs:
Yes
This adds invisible text to start of block to sort it out - thanks for highlighting the issue
So corrected (corrected) version using invisible text option looks like this now
Try $- if you're fine with a gap:
The spec of that is "$- something2 %m".
BTW why does the long input dialog appear when editing a "Title text"?
BTW: the concept of variant input assisted with reporter is borrowed from @wunder_wulfe project
Slightly crazy idea:
fill the dropdown with the block's variable names of the enclosing custom block (requires JS during edit).
Given custom block definition
dropdown is filled with
Input Slot Option:
function(){
let vars = this.parent?.parent?.parent?.variables?.vars;
if( !vars){ return {}};
return Object.fromEntries( Object.keys( vars).map( it =>[it,it]));
};
Getting cleverer and cleverer
I've been keeping away from using JS in menus since the change came and and I'm waiting for Snap! 7 to be released before revisiting the use of it.
Block variables, as opposed to script variables, have a pretty narrow utility. In particular, procedure inputs that are expected to be different in each call to the block should really be script variables.
I hate to say it, but this is a good use case for the Variables library, which Jens hates. You could dynamically create script variables for everything in the names list.
It'll be even better when I finally, if ever, get macros done, because what you really want is a block that takes the names list and the variadic input list as inputs, and creates script variables in its caller.
The Snap! 7 situation will be much like what it is now; you'll have to enable JS Functions to use JS in an input menu, except that libraries will be pre-approved.
Yes - but I've been caught before developing using dev so not going down that path again
Variable names in this scenario must be known upfront before running block, so they must be a part of some constant definition. Block variables are also much better in terms of performance (as script variables seem to be repeatedly recreated at runtime)
But yes, a kind of "transient" attribute for block variables would be very useful. Or block to clear.
I made a variant of the block
which read the declaration of a variable from the comment in the custom block header.
I wonder how you made it use the comment to generate them. Could you post a link?