I am not seeing any compelling reasons to avoid supporting negative indexes *or* slices here.

If I had to guess about the confusing semantics of negative indices, I would guess it's the fact that the index in the -1 position for a non-empty Path will always be `Path('.')`. Since that's not terribly useful, it might be reasonable to have negative indices start counting at `len(p)-2`.

That said, I don't think this is a big deal, and I think we have more speculation on why this was avoided in the first place than we have actual objections to changing it, so I vote for changing it.

I think our best option is to say that the semantics of indexing `.parents` should be the same as indexing the result of casting it to a tuple, so this should be true:

    p = Path(x)
    assert p.parents[y] == tuple(p.parents)[y]

For all values of `x` and `y`.

I've gone ahead and changed the version support matrix to 3.10 only, since I think that this was a deliberate choice and we should be considering this an enhancement rather than a bugfix. That said, I'll admit that it's on the borderline — the semantics of sequences are unambiguous (see, which says that sequences support both slices and negative indices: https://docs.python.org/3/library/stdtypes.html#typesseq ), and PEP 428 explicitly says that .parents returns a "an immutable sequence of the path's logical ancestors": https://www.python.org/dev/peps/pep-0428/#sequence-like-access . So if someone is motivated to try and make the case that this is a bugfix that could be backported to earlier supported versions, I won't stand in their way.