I believe that when David was talking about multi-pass iterability he wasn't referring to an iterator that can be told to "start over again" but to an iterable object that can produce multiple independent iterators of itself, each one good for a single iteration.
To an excellent first approximation, it makes no difference. I read David the same as you, and that's where my "no such distinctions" came from. The "likewise" in "Likewise for a way to tell a multipass iterator to 'start over again'" means "and in addition to what you asked about, not that either" (which is something other people have asked about, and more often than what David asked about).
The language does make a distinction between an *iterable* object that may have only an __iter__ method and an *iterator* that has a next method.
Sure. At the wrapper-level David works at, all Python supplies here is PyObject_GetIter(x), which returns an iterator or a NULL, and in the former case the only useful thing he can do with it is call PyIter_Next() on it. There's simply no way for him to know whether calling PyObject_GetIter(x) again will yield an iterator that produces the same sequence of values, or even whether it will yield an iterator again at all. He could hardcode knowledge about a few types, like, e.g., the builtin list type, but that wouldn't even extend to subclasses of list; similarly a subclass of file may well fiddle its iterator to be multi-pass despite that the builtin file doesn't.
... A Mamba programmer called Nero Hsorit has speculated in a mamba-dev posting that in an alternative universe in a language called 'Cobra' people kept getting confused between iterators and iterables :-)
David can't get there from here with or without confusion <wink>.