"=" bug

I ment it only evaluates the inputs on the last block in the stack

okay, but that makes that bug useful again

It’s still a bug, there no reason the block shouldn’t be looking at the inputs
There’s really no use for this as the answer will always be the same because you cannot manipulate it

untitled script pic (6)

Block made using this bug. Useful for detecting local blocks from variables, because if you split a local block to reset its inputs and set it to variable the project wont be able to load, so with that we can put local block to variable without resetting its inputs, and then use that to detect local block

untitled script pic (7)

untitled script pic (8)

Made a block that temporary will fix that bug

I don’t quite understand the use case when you can still just use split by

There are a handful of blocks that already had meanings for lists as inputs before we had hyperblocks: =, ≠, identical to, is _ a _?, and join. For example, = applied to two lists checks whether the entire list is equal to the other entire list (apart from this bug). (JOIN (LIST A B) (LIST C D)) is (A B C D), not ((A C) (B D)). These are primitives, not in any library. The APL library provides scalar (hyperizable) versions of those blocks.

So you are confirming that this is how snap is coded? That stacked blocks inside rings behave as lists?

Adendum to this, I think that every data type should (when called as one) be a list with 1 element so you don’t need to convert it into a list
This basically would just convert any data type slotted into a list slot into a list no matter what
“Is a list” would report if it has more than 1 element

Somewhat like this

No. I was answering your suggestion that all blocks should be hyperized by explaining why some aren't.

imagine putting a block inside of other block using join, for split with 2 inputs it would be harder than for custom block with 1, also it just looks nice