Is it normal ?
I would expect to receive 0...
This is just an edge case that no-one has found before
[edit] I drilled down into the Snap! code and it seems to be an issue at the JS level caused with JS returning 0 if you try to find "" in "abc" using result = "abc".indexOf("")
I wonder why JS doesn't return -1 like it does for "abc".indexOf("z")
It is because the first zero characters of "abc" is in fact "". It is actually correct, if a bit strange.
Well - that's for a philosophy discussion 
I agree, this isn't a bug. I'd be interested to know the context in which @loucheman discovered this; was it just in fooling around with the block, or did it actually come up in a program? Because it's an unusual question to ask.
A kind of analogy is thinking about what AND with no inputs should report. The right answer is True, which always surprises people. But if it has no inputs, then all of its inputs are True. (OR with no inputs reports False, which is another surprise because we usually think of OR as being more permissive than AND, in the sense that if AND of a bunch of inputs reports True, then so does OR with the same inputs -- except in the case of no inputs.) Asking for the position of the empty string in a larger string is the same sort of weird question.
I think, at Snap! level, if the search item is empty, then the index of the search string in any other string* should be zero
This is to match with all other index type reporters
e.g
accidentally !
That's not bugging me, I just wanted to notify...
Are there more than those two? There would be if FIND FIRST returned the index, I guess, but it doesn't.
And looking for an empty string as a substring of a string is different from looking for an empty string as an item of a list. For the two cases to be parallel, you'd need a list block like
and then if you gave that block an empty list as the first input, the right answer would be 1, same as in the green POSITION OF block.
I thought they were false (that's what Scratch does).