You mean, like this?
Yep! Thank you very much!
Update, I got the thing to kind of work ish?
It’s a start but it only works for blocks that have 1 stack block as their definition as it only reports the first block with whatever inputs are inside it
Update
IT WORKS!!!!!!!
Almost.. as you can see the “with inputs” isnt kept, well it is but it gets erased there’s no way that I can tell to properly do that as “run” doesn’t work with “join”
Here’s a version what works “with inputs”
As you can see with these. join needs the block ringifyed
Does anyone know a way around this?
I’m not sure if it helps, but perhaps my recent observations may increase your insight as to how blocks are turned into lists and vice versa, and associated quirks.
I’ll have a look at your INTO DEFINITIONS block one of these days, that may help me understand as well 
Other than that, all I can say is: metaprogramming Snap! is mostly a matter of trial and error learning by doing.
Btw where can I find a working version of INTO DEFINITIONS ?
It’s actually inside the “databasemore stuff” project
https://snap.berkeley.edu/snap/snap.html#present:Username=cookieclickerer33&ProjectName=Databasemore%20stuff
I’m still working out a way to make the run stuff work
Currently stuck on getting the variables that need to be run to work with the blocks
So I found something interesting! It turns out for the run block to accept the blocks they need to be double ringifyed!
Shouldn't there be WITH INPUTS: (INPUT) in there somewhere?
@cookieclickerer33: When definition code is in list format, input parameters are either the final items of the list (if the code consists of a single block), or the final sub-items of item 1.
I don’t think this is officially documented for users.
Yeah I think the final implementation was about a day before the release so nothing is very well documented. I'm spozta fix that too, between now and Snap!Con. :~(
Edit: it actually does work, it just doesn’t save the inputs if blocks using them are deleted
I’m still stumped at how to make the “run” block have its “with inputs” be filled properly and definitely need help with that
Okay this new 9.0 update might actually help depending on what this does
If it does what I think it does then this should make things easier
But the issue of join not keeping inputs still remains meaning this could be impossible without a fix
I still have no idea if this is actually a bug or a just a result of bad programming, but according to everything else this should be working fine
I think I've figured it out
if you give me some time ill send it to you when I'm done
Definitely!
I’ll add credits to all the contributors inside the blocks when the full thing is done
This change adds no new functionality; it just changes the syntax for the same old things in order to emphasize the possibility of the "input list" mode. And the notation is far from settled, so don't start writing code around it. (I.e., don't write code you care about in dev. The existing notation will be translated to whatever new notation we have in 9.0 when it's officially released.)
Yea I assumed so
I wasn’t Gonna Don’t worry
The block is almost done! It supports commands, reporters, and predicates, but doesn't support custom blocks with c-block inputs for some reason. And rings are kind of janky sometimes.
Oh, and recursive functions kind of freeze the project.
Here's the project:
https://snap.berkeley.edu/snap/snap.html#present:Username=joecooldoo&ProjectName=Replace%20Custom%20Blocks%20w%2F%20Primitives
Seen!