I agree that it is coincidental. It does not make sense that you would have to find an index, as the indexes are known, they are addresses, the value is what you would probably intuitively want to find.
Selecting something is different, though, as is noted.
Perhaps finding 3 or 8 would be better to avoid a “Stroop Effect” that seems to be going on here, though, as the index and the element are the same value. (indeed, even the same object)
If the methods are indeed Enumerable methods, we could change “enumeration” to “Enumerable” methods and link to the documentation for Enumerable Array#find. But “enumeration” is not necessarily tied to this, it is all the methods including methods that are not defined by the class’ instance being used, some (many) coming from Enumerable.
But also, I wonder why it is thought that the behavior of find is ambiguous, since the documentation specifically states:
Returns the first element for which the block returns a truthy value.
It states “element” not “index”.
That said, there is prior knowledge that is not necessarily clear, where we state in Bird Count that (at least) some of the methods are Array methods, when they are indeed no, but come from Enumerable instead.
There is something to be said for “lies to children” to be discovered later with some expertise that it is not precisely correct. But I do feel like perhaps this can be addressed by more precise indications in the prior exercise, rather than waiting here to find out that perhaps the documentation is not consulted.
I would not change the select example, though. It seems to be clear, and if the find is changed, it will not be coincidentally the same number we are looking for and should result in selecting [5, 8, 13].
