Was this what you meant? I unringified the call to ITEM in what you showed.
I think we're in agreement that the call to LIST with one input makes a list of length one, whose sole item is the (ringed) SPLIT block. So, ITEM 1 OF that list is the SPLIT block itself. And so CALL calls that.
Here's the way to think about all this. First you have to believe really solidly in the usual evaluation rule, with no rings or CALLs involved: Snap! first evaluates a block's input expressions, and only then does it call the block itself, with the values of the inputs. So, SAY (2+3) with no rings first computes 2+3, giving 5, and then passes the already-computed 5 to the SAY block. Right?
So now, what does putting a ring around something do? It prevents the evaluation of what's inside the ring, so the expression itself (that SPLIT for example) is the input value.
And what does CALL do? It requires an expression as the value of its input, and it evaluates that expression. So, the most common case of CALL is that you drag an expression into the ring that's built into CALL. You say CALL ((2+3)) where the double parentheses are meant to look like a ring, and you get 5.
As a special case, if you drag a variable into the CALL input slot, we assume that you meant to evaluate the variable block, and that the value of the variable is the thing you want CALL to call.
Now, if you're still with me, an even hairier special case is ITEM, because maybe (as in your case) you want the ITEM expression to be evaluated, because the items of the list are ringed expressions, or maybe you mean the ITEM invocation itself as the expression for CALL to call. This would be the case if the list items aren't expressions, but are, you know, words or numbers or whatever. So, since we don't know what you meant, we just do the regular thing, which is to leave the ring around the ITEM expression, so it isn't evaluated until CALL runs. To do the thing you meant, you have to right-click on the ITEM block and choose "unringify."