I cant post my tutorial here because Body is too similar to recently posted
That's just an oversight, not a design decision.
Done.
That's why you won't see internal definitions in 10.2; your issue is one of many that have to be resolved. My off-the-top-of-my-head idea is that the script of the outer block would start with an invocation of the 
block to define the helper. So, no, we wouldn't have to report scripts with hat blocks -- although that is an issue for the 10.2 feature, since those internal scripts aren't exactly internal definitions. But we could solve that problem with a DEFINE that defines a WHEN (input name) MENU CLICKED block. Wait and see... or experiment with the dev version. :~)
I'm just gonna post this tutorial here:
To create a dynamic dropdown menu, you have to create a new input value, and select scripted:
To add values, drag when [ V] menu clicked::control hat into the block editor (one of the most cursed actions you could possibly do in Snap!), and the dropdown in the hat will populate with all of the scripted option values. To add options, you must append report (list [option 1] [option 2] @addInput::lists) to the end
haha I've been thinking about making a feature request for this but never got to it.
As one of the goals of snap, this feature would making blocks have the same usability as text.
what?
@ego-lay_atman-bay
Since I'm an admin (to be able to update snapblocks on the forum), I can move posts.
Cool, but your trust level is still "regular", how is that possible?
Because the only other one is "leader", and I'm not a leader (I'm technically not a moderator either, I just have admin powers). I honestly don't care about what trust level I'm at, since they're all the same*.
I thought trust level also defined what permissions and abilities you have?
I wonder if creating a specific structure for internal procedures is going to be worth the trouble, as they can already be defined using Snap! ‘s current syntax:
The reason I created the topic Dropdowns from db? two years ago was to make just this block, happy I could finally do it today :D
Yes, I think so. Creating procedures by means of explicit lambdas is significantly clunkier than a make-a-block definition, for at least two reasons: the ring doesn't have a title text, so you can't include labels for the inputs, as in the GO TO X: () Y: () block; and you have to grab a CALL block whenever you want to call the helper. I know this is what people these days call a "first world problem," but in my own Snap! programming I find myself avoiding that notation, instead making the helper a separate toplevel procedure with extra inputs to carry over the main procedure's inputs. (In dynamically scoped Logo, you don't need the extra inputs to the helper.) You did the same thing in the streams library, defining hidden toplevel blocks as helpers to a visible block, rather than using internal lambdas. To say all that in a more abstract way, that notation doesn't feel like block programming, because there's no block you can grab.
That's only for specifically that menu and local blocks in sprites. You can't do the same with the new dynamic dropdowns (which is what @mr_owlssssnap2 was talking about).
Is that really there, I can’t reproduce it.
Create a sprite only block in a sprite, select that sprite in the second menu of the ([ V] of [ V]) block, then click on the first menu.
Oh ok. I didn’t know I needed to select the second menu first.
Let me exploit the behaviors of morphs and see if it was possible 
Anyways, I meant to acknowledge that the developers have done blocks in dropdowns before so why would they not be able to implement such feature?
I just tried to, I don’t think it is. Even using the ring removal block
Seems like the new dynamic drop downs become empty when the value of the menu list is not a text/ number.
Ooh. Hat blocks in the custom block definition is clever.