Currently, this proposal coerces arguments passed to drop and take to integers without range checks other than for negative numbers because ToIntegerOrInfinity is used to coerce the argument passed in.

This has the potential to create confusing behavior - for example naturals().take(NaN) and naturals().take((x) => x < 15) and naturals().take('aaa') all return an empty iterable.

I think most other places the spec does this get away with it by checking an explicit range (e.g. toString on numbers requiring the radix being at least 2) but admittedly some places don't (e.g. toExponential happily accepting NaNs).

I think it would provide better developer experience to get RangeErrors on NaNs (basically ToNumber the argument first and throw a RangeError on NaNs).