I hope it's fine to add to closed topics here.

I agree with the decision that islice should not handle a special case of sized containers vs iterables.

However, I think that the support of negative indices in islice would be nice. A simple use case would be to get the last element of an iterable.
I had to write my own code for that (you may read and/or use it if needed), because I needed this algorithm in my analysis. Here is the link to my function ISlice._run_negative_islice in my architectural framework for data analysis: https://github.com/ynikitenko/lena/blob/master/lena/flow/iterators.py#L150 or on https://lena.readthedocs.io/en/latest/flow.html#lena.flow.iterators.ISlice (I'm afraid the correct link might change later).

I also agree that to support negative indices would require more work. Indeed, it seems that for each combination of positive/negative start/stop it required a new algorithm! I didn't implement negative steps.

However, I think that because it's not easy to implement, it would be even better to include that in the standard library (because it would save other people from writing that).

If we care about code reuse: I think that negative indices make the algorithm more useful, while non-trivial steps are redundant, because they can be implemented by a composition of a slice with step=1 with a simple slice with start, stop=None, None with step!=1.

Negative slice fundamentally changes the algorithm: if one wants to have the flow inverted, fflow[0, None, -1], one would have to store it all in memory! Anyway it's easy to make this in a separate function. So I think it's more functional to implement negative indices and discard negative steps (or non-trivial steps at all).

About drop_first, drop_last suggested above: I also think that they are redundant and would be better incorporated into islice.