I made 2 blocks from (what might be) an oversight of the [scratchblocks]item (1 v) of (list)::#d94d11 reporter[/scratchblocks] block, but I'm not entirely sure
a feature of the [scratchblocks]item (1 v) of (list)::#d94d11 reporter[/scratchblocks] block.
No credit needed. 
The ability to get a key from a list of key / value pairs is not an oversight, it's rather a controversial feature that was added in snap 9.
How's it so?
Are you asking how it's controversial?
Yes.
Well, it's controversial because I don't like it. It just feels wrong to type text into a round (number) input.
Hahaha! You tell 'em!
We've already established in a different thread that my memory is like a sieve, but I think the story is something like this: The Europeans were talking about exposing the Javascript dictionary data structure to users, because it's very efficient. I didn't like the idea because we had started with the idea of providing just a minimal toolkit that would still be quite adequate to allow users to invent their own programming language features, namely, first class functions, with which users can invent any control structure, and first class lists, with which they can invent any data structure. We bragged that we could make a serious computer science language by adding just eight blocks to Scratch.
In particular, our theory as teachers was that kids would learn a lot of computer science by building their own implementations of the things that those inferior programming languages (not Scratch, I mean Python and JS and that crowd) led them to believe had to be provided by the programming language wizards -- for example, that you can't do object oriented programming unless you're using a special object oriented language. But also that even something as simple as a FOR loop had to be provided as a special syntax in the language.
Since then, though, we have been slowly creeping toward being more like those other languages, providing everything under the sun as primitive. Dictionaries are an example of that, and a particularly egregious one because it's really quite easy to implement a dictionary as a list of key-value pairs. (See ASSOC in the file utilities library.) But that implementation is slow if you have a large dictionary -- 10,000 entries, say. The Javascript implementation uses hash tables, for constant-time lookup. (You can build hash tables in Snap!, too, efficiently, but the code is no longer trivial.)
So we were disagreeing, and then they proposed a compromise: Dictionaries would look to users just like lists of key-value pairs; you could make one out of two columns of a spreadsheet, for example. The dictionary would look just like a two-column spreadsheet, but could be accessed by giving nonnumeric first inputs to ITEM. You could use the dictionary just like any other list; for example, you could MAP over its key-value pairs and get a new dictionary.
This is way better, I'm mostly convinced, than having an entirely separate dictionary data type. But I still miss the days when we were all about proving how little you need in your language to support building your own dictionaries or whatever.
You're just too accustomed to Scratch. :~) All our other input slot types let you put any expression into them, and if your expression reports a value that isn't in the domain of the function you're calling, that's a runtime error, not a syntactic error caught in advance. In Scratch, whose data types are mostly just numbers and text (Booleans are allowed in very limited contexts), they could realistically have the goal of never showing the user an error message, but instead preventing the user from making the error in the first place. But in Snap!, that restriction on typing non-digits into a numeric block is this strange exception. And it gets in the way of using exact rational or complex inputs to arithmetic operations.
Uh, no. Those can be put into any input slot, and behave like booleans (true = 1, false = 0). Reporters on the other hand, can't go in boolean slots (with the exception of a few list blocks, for some unknown reason), which limit what you can put in a boolean slot.
When it comes to inputs in snap, I really view them as type suggestions, similar to how python handles types. Anything can go in them, but there's a specific type of value that is expected to go in. With number inputs, it's an easy way to say, hey, a number is supposed to go in here, and you can't type text in it because I'm expecting a number. Now yes, you can put non-numeric text in number inputs via a dropdown, but that's like saying those are special values that the block also expects. I just don't like the idea of typing text into number inputs because at that point, you might as well change it to a text input.
i feel like metaprogramming (or some general kind of macro system) is missing from that list. sure, you could write a dsl as one big chunk of text, but that doesn't have any place in a block based language!
i still think snap has always overcomplicated some things and is still missing some other essential things. mainly the way code seems to interact with the rest of the program. why is it so easy for code to overwrite the project it's running in? code can make clones permenant, create and delete blocks from the pallete, create and delete permenant variables, and all sorts of other things. on the other hand, there's still no good way to create custom events, no way to create new block shapes (for example, blocks used in a declarative dsl really shouldn't be mixed with imperative code), no easy way to prevent other code from destroying a project, no easy way to ensure a block is a pure function or turn it into one, etc.
i think a truly minimal and usable block language would need to be turing complete, and have incredible tooling to edit custom blocks and the rest of the gui, notably including custom block shapes, custom buttons to create blocks, and all this in new palletes. nothing else is needed. want first class functions and lists? make them yourself, in any shape you like.
Ah, you're a macrologist! Yes, I agree, on my list of things to do someday is implement Scheme hygienic macros on top of our existing metaprogramming primitives. (Feel free to do it for me!)
But...
First class lists can be made out of first class functions, yes. But that doesn't clear my usability bar. Data structures are a fundamental idea in programming languages. Building lists (as objects) out of functions requires too much sophistication. We're a language for kids, after all.
There's probably some way to build lambda out of macros, but I haven't learned it yet, especially since macros are implemented out of functions!
As for the stuff in your middle paragraph, I'm having trouble visualizing what you're after, and why. Block shapes are a frill. I wish they were all ovals with tabs, so you could both compose it with other blocks and put it in a stack (a sequence).
with many text languages, you have access to plenty of compile time tools, and with lsp, you can get errors long before compiling or running code. as far as i'm concerned, this is essential
snap completely wastes any potential of block shapes. personally, i wouldn't allow stack blocks inside any round blocks, and i wouldn't provide any round blocks that aren't deterministic and pure. yes, that means random would be a stack block with an upvar, same with the timer and various others.
more importantly and what i'm considering here is a dsl. in a dsl, you can't just use whatever syntax and functions you want from the language used to create it. in fact, you'd almost certainly get an error from the lsp, long before you even try to do anything with the code. when i say custom block shapes, i mean something like a custom block notch that doesn't fit other blocks. the two types of block stack would become entirely incompatible. any data structure you like, now in stack form!
made an integer type and don't want to accidentally put a decimal number where an integer should go? make an integer block shape!
scratch and snap seem to avoid blocks getting too long by putting massive amounts of state in each sprite, and forcing some things to be global. the new beetleblocks plugin everyone is talking about seems to only allow one 3d scene, if you want to switch between scenes you need to build all the shapes every time.
consider a "use" c block where you can put in any type that has a particular use feature, and every block within automatically has a relevant slot filled in and hidden. maybe split all such blocks into two halves (left side explicit, right uses left), and the use block adds the correct notch to use the right side by itself.
there's SO much potential in block shapes, and so far i've seen every project just use it as a hint. honestly, if you need a hint, just color the block. (on that note, allow multiple colors on a single block!)
I see, it's strong typing you want.
This has come up often before, and I don't think you're going to convince us. There's a reason everyone hates Java and programs in Python or Javascript instead. (Yes, I know there are still 23 people left who love Java; no need to tell me if you're one of them!) Especially in a language for beginners, we don't want people to spend an hour having to struggle with syntax before they can compute 2+2. (It is a myth that block-based languages don't have syntax. (I'm not accusing you of believing it.)) Our users are not writing gigantic, life-critical software in teams of 5000.
Dan Garcia has been pushing us to add a voluntary input type checking feature, on an input-by-input basis. We haven't totally ruled that out, because it won't bother you unless you want it (or, more likely, your teacher insists on it, which is one of the arguments against it), but it's not high on anyone's priority list. Too much exciting else to do!