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.
[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) ]
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.
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.