After more thought, I'm -1 on this.  "Consistency" is a weak argument in favor of this.  We need to be more use case drivenm and it there is no evidence that this is needed.  Also, there is a reasonable concern that using negative indices in a format string would be a bad design pattern that should not be encouraged by the language.  And, there is a maintenance burden (just getting it right in the first place; having other implementations try to get it right; and a burden to custom formatters to have to support negative indices).

I do think we have a documentation issue.  This thread shows a number of experienced Python programmers who get "surprised" or perceive "consistency issues" perhaps because there isn't a clear mental picture  of Python's layer structure (separation of concerns) and where the responsibility lies for the supporting negative indices.

For the record, here are a few notes on where negative index handling fits into the hierarchy:

Negative index support is not guaranteed by the collections.Sequence ABC nor by the grammar (see the "subscript" rule in Grammar/Grammar).  It does not appear in opcode handling (see BINARY_SUBSCR in Python/ceval.c) nor in the top abstract layer (see PyObject_GetItem() in abstract.c).  Instead, the support for slicing and negative index handling appears at the concrete layer (see listindex() in Objects/listobject.c for example).

We do guarantee negative index handling for builtin sequences and their subclasses (as long as they don't override __getitem__), and we provide a fast path for their execution (via an intermediate abstract layer function, PySequence_GetItem() in Objects/abstract.c), but other sequence-like objects are free to make their own decisions about slices and negative indices at the concrete layer.

Knowing this, a person should not be "surprised" when one sequence has support for negative indices or slicing and another does not.  The choice belongs to the implementer of the concrete class, not to the caller of "a[x]".  There is no "consistency" issue here.

IOW, we're not required to implement negative slice handling and are free to decide whether it is a good idea or not for the use-case of string formatting.  There is some question about whether it is a bad practice for people to use negative indices for string formatting.  If so, that would be a reason not to do it.  And if available, it would only work for builtin sequences, but not sequence like items in general.  There is also a concern about placing a burden on other implementations of Python (to match what we do in CPython) and on placing a burden on people writing their own custom formatters (to closely as possible mimic builtin formatters).  If so, those would be reasons not to do it.

my-two-cents,

Raymond