Actually I'm making indexOf faster by doing this. The index is already passed as the second parameter I'll just leverage this free gift.
Since this is lazy execution, indexOf makes the entire thing really fast in fact. Imagine only looking as far as the 4th item (because whatever it is, it happens to be the one that matches). Then imagine having 1 million items in the list. It really only executes the chain 4 times, rather than execute everything then find the the item that matches, even if it's only 4th position.
This is why methods like split, indexOf, take, get, contains, every, and first are very fast, they stop as soon as the predicate is matched, after only having executed the chain until then. And in the case of string split, it doesn't have early termination in native JS.
Edit:
I'm going to scrap what I did to indexOf.
suppose you're given a partial chain that already has a few filtering ops attached to it, you can just tack a pluck().indexOf() onto the end of it to still get the original index (assuming it passes the filter anyway).
It shouldn't work like that. Filter dirties the chain. In practice it makes sense for indexOf to return only the new index after filtration. I was thinking maybe not, but this is a lazy execution environment. There are times can no longer get the original index of an item. After some time that data vanishes further into the chain you go.
Take for instance:
Link([0, 1, 5, 4]).filter(function(n) { return n > 3; }).skip(1).indexOf(5);
Link([0, 1, 5, 4]).filter(function(n) { return n > 3; }).skip(1).indexOf(5, true);
They both return -1 (does not exist), but shouldn't #2 return 2? Well it would if the combination of the filter and the skip doesn't destroy element 5 from existence. See, it only works to get the item in the original array if it survives the chain of operation. So, it makes sense to use the filtered value because in this case at least it's guaranteed to produce a result in alignment with the data it operates on.
But I do see one use of an unfiltered index version of indexOf. There is a speed increase. If you filter out even numbers and you know the item is odd, but you want the original index, and the item is somewhere within the first half of the list. We can filter out the numbers we don't need to check, get to the odd number faster, and then get the index, returning the original index rather than the filtered index. But it might almost be faster to just get the index of the odd number anyways, I'd only see this as a speed increase if you work with millions of numbers. Filter is fast, but indexOf is faster.