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?
Yes, to make help screens for custom blocks.
Ok.
No, I meant, nothing in 7 is going to make using JS-powered menus any easier than it is now!
Last update today 
Block to clear all block variables.
Easier wouldn't be a problem - harder would be the problem
I don't think it'll get harder, i.e., you have to enable JS to do it, and that'll still be true, but no other obstacles. It sounded to me as if you were waiting in the hope that it'd get easier, the way using libraries will get easier in 7.
No - just waiting for it to reach at least beta and preferably RC stage.
Once bitten, twice shy as we say over here
@kinestheticlearning In reply to your questions on other thread about why not use variadic slots
One of the problems of variadic inputs in a custom block is that if you make even the slightest edit to the block definition - any existing use of the blocks in a project immediately lose their parameters.
I am looking to try and persuade a library author to add additional options to their blocks and I want to keep things as simple as possible in order to boost chances of my enhancements being accepted
I decided that Dardoro's clever ideas might be a step too far so just going to try a simple approach at first.
Could I persuade you to delete your comments in the other thread to keep it on topic please?
Done.