There are several sub-questions going on here, so I can see why you want a split, but I don't see a very clear separation. Ironically, "making the CONTAINS block" is not one of the topics; it's a primitive! The topic you're seeing is "how do you get the INPUT LIST: variant of a block?" to which the answer is to drop a list over the arrowheads of a variadic input. Another piece of it is how to get case-independent searching, to which the answer (not given above, I think) is that CONTAINS uses = for comparisons, which is already case-independent! :~)
If I understand correctly, the CONTAINS primitive that you are referring to is the one from the 'red category' and it searches through items of a list. However this topic seems to be about searching for a substring of a text (not searching for an item of a list). Maybe the title should be "making of a (green, not red) CONTAINS block"?
I ended up doing it in JS after all, so I could use the flag set by USE CASE-INDEPENDENT SEARCH, which is in the world's JS variables because at the time we didn't have the Variables library. I may rethink that, now that we do have it.
. The other blocks in the library check the flag it sets to decide whether to use case-indpendent (yay!) or case-sensitive (boo!) comparisons. That block doesn't set a Snap! variable; it does this:
var world=this.parentThatIsA(IDE_Morph);
world['stringLibCaseIndependentComparison'] = flag;
so the other blocks need to look up the flag in JS.
I wrote it that way because libraries can't include variables. But now we have the Variables library so I could have
Yeah, I know, I could do that. But the reason for case conversion is case-independent comparison and that should be in lower case I think. Actually the official right thing is toLowerCase(toUpperCase()) because of the stupid ß which is equivalent to "ss" and becomes "SS" when converted to upper case. Maybe I'll make the Snap! lower case block do that round trip.
P.S. Reading this I see that I didn't really answer the question. Arguably every JS string function should be in this library. But in fact it's just the things I need; the library first appeared when we were doing web page scraping in BJC.
Wait, what? Users may need things you do not need and I am quite sure a large number of users do not know JavaScript, if not most; and may also be struggling to find a Snap! implementation.