Raymond,

> The existence of use ABCs like MutableMapping is being drowned-out by one-trick-ponies.  We're developing an unfavorable ratio of theoretical building blocks versus the practical tools.

Why do you think they are "theoretical"? FWIW, a simple search on GitHub for abc.X gives this:
Sequence 322K
Mapping 267K
Iterable 244K
Container 99K
MutableMapping 77K

I don't see any pattern here (although this may be only anecdotal evidence :-)

> Other than a feeling of lightness, I don't think this proposal does anything for us.

This proposal makes more sense (and motivation) in the context of static typing, since it is a good way to know how __getitem__ is going to be used -- from its static type. Something typed with Subscriptable[int, T] would accept both Sequence[T] and Mapping[int, T]. The latter two are  currently differentiated by __reversed__ (Sequence is Reversible as opposed to Mapping).

Concerning an invariant that order of iteration is consistent with indexing by subsequent integers, I think this can't be checked reliably neither statically, nor by any simple runtime isinstance check. For example a subclass can override Indexable.__iter__ and break the iteration order. We can still add it, and rely on user cooperation.

Anyway, I am not insisting on adding either Subscriptable nor Indexable, but I think it is important that these things are discussed in view of PEP 544.

Alternative proposal would be to add Subscriptable and its subclass Indexable only to typing as protocols (with some special-casing in type checkers for the latter to provide a higher level of contract).
(Concerning the name, I think Enumerable sounds better than Indexable, IIUC the idea is to work correctly with enumerate.)