If I create a variadic input with 3 intial slots, 3 min slots and 3 max slots I can click on arrow and get 4 slots
yes, then it's no longer variadic. Not planning to change this.
Fair enough 
What? What do you mean by "no longer variadic"? It is; you can switch back and forth between 3 and 4 slots. Is there a reason you consider this desirable? I mean, a variadic input constrained to one number of slots is a little weird, but I can see a use for it: an RGB block. Seems to me that "max 3" should mean max 3, not max 4. (And if you do 2/3/3 then then the actual max is 3; it's only if min=max that you get this weird behavior.)
If the user specifies something that's not possible, such as min>max, then I wouldn't mind weird behavior.
If you want exactly 3 input slots, make 3 input slots. If you want either 2 or 3 input slots, that's possible. If you want a list type input, that's also possible. Don't get on my nerves.
I ran into a similar problem recently when I tried to make an IBM Punch card block. (for reasons.) I tried to use variadic inputs to save a bunch of time (I'd need only 12 instead of (* 80 12) inputs), and I tried limiting the size like that and I had the same problem.
but what about using a not-actually-variadic variadic input to add an input list?
I don't mean to, but I honestly don't understand why you like this behavior.
leaving this buggy seems like the kind of thing that would cause more bugs down the line. if you think a list input is a sufficient replacement for a variadic, why have variadics at all? fixed length lists aren't a thing either and in many cases would make it difficult to tell what the block's for.
the GO TO X: () Y: () block would certainly be nicer as a two slot "variadic" so you could drop a list in without replacing the block. yes, there's the GOTO with the dropdown, but there's no matching block for glide. atan2 would also benefit, as you would be able to drop a position directly into it. costume stretch and new costume dimensions would also benefit.
perhaps also number ranges could do the same thing, so you could use PICK RANDOM or FOR with a list.
using the input list isn't a particularly robust way to deal with large numbers of inputs, it makes it extremely difficult to change the lot and the implementation breaks the moment you add another input.
even if it had no uses (it has plenty) that's not a particularly good reason to leave it as is? the current behavior is clearly a bug and it could lead to more bugs later. letting it get created through the ui is just confusing. letting it get created and used by the various metaprogramming blocks could lead to weird inconsistencies in program logic that are annoying to deal with.
Jeez. All the usual smart folks again...
Well, I really am not trying to annoy you, but bear in mind that I'm one of the people who don't understand you. I think you're expecting us to read your mind again. If you said either "yes it's a bug but I don't think it's worth fixing" or "I have in mind this use case" then we could go away happy, or maybe unhappy, but at least knowing which.
But instead you say "then it's no longer variadic," and I'm sure you know what you mean by that, but it's totally not clear to anyone else, and then "Not planning to change this," which, again, I'm sure you know what you mean but it's unreasonable to expect anyone else (even me) to make sense of such a gnomic utterance.
So stop picking on sarpnt.
on the contrary, some folks here - sarpnt being one of them - compensate their engineering weakness with opinion fervor about what's right, and more often about how I'm doing things wrong. Remember the time I gave in and pulled the optimizations they'd been lamenting about in this forum for months, and then all hell broke loose and schools couldn't use Snap! anymore?
If and when I get around to changing something about variadic slots I might do it, but in the meantime I couldn't care less about people who want to specify a static list in inputs as variadic one. C'mon, don't be ridiculous.
Just to add (since I was the one that reported this as a bug) that I accept that making a variadic input a fixed length is not a good thing to do
I just ended up trying it out as I've been using variadic slots quite a lot in the past couple of weeks for option slots in various reporters
A hammer isn't the right tool in all circumstances
As the OP, I've marked Jens answer as solution - so can we close the thread without further "discussion"
Nah, I did "fix" this in today's patch. But I'm not at all happy with the direction that variadic inputs and metaprogramming is taken here, and I even flat out regret going down that direction with Snap. Sigh. What started out as an initiative to make introductory programming more approachable and friendly now has to justify itself for not being less of a "toy language" than Python and for not supporting quirky "elegance" such as:
(which you can now do as today, but, gosh, please don't!)
Yes, it would! I usually avoid metaprogramming, but it seems like the right choice in this case.
"When we can finally get rid of it, people will spend years trying to simulate it" - some guy talking about emulation, paraphrased
That's because "progress" doesn't always improve everything. I have a simulated MacOS 6 running on a simulated Motorola 68000 running on my shiny new MacBook Air, so that I can run a great program called Intellidraw that you can't get any more.
That particular example isn't compelling because since BYOB 3 you can instead say
but I can imagine wanting to do it in a block with a zillion inputs, like that all-possible-options URL block in some library or other, two of which form a grouping.
Maybe we should take this part of the conversation offline.
stop it, for god's sake.