Martin's preceding comment asks:
  "How else could you interpret 'unordered collection' but as 'having arbitrary order'?"

This question seems to me to read into the docs much that is not there. There are so many possibilities ...

Keep in mind that I proposed a docs patch believing that the docs should communicate to users that a particular iteration on a set may produce a different order of elements on *sequential* runs of an *unchanged* source.  Martin been claiming that the docs do communicate this (although he has been somewhat vague about the target audience).

Here is a simple description of a class whose instances are plausibly considered an "unordered collection" that would not have that "volatility" property. (The question here should not whether this is a silly class but whether Martin is actually drawing a valid inference from the existing docs rather than just reading his experience into them.)

Call the class ``Silly``. Initialize a Silly instance with an empty list and a deterministically seeded instance of random.Random. A Silly instance has an ``add`` method that computes the length of its list N and picks an insertion point for the new item using randrange(N+1).  (If you want a Silly instance to behave more like a set, we can insert an element only if it's not in the list.) Iteration on this object is to be iteration on its list, but no indexing or slicing is to be provided.

A ``Silly`` instance is plausibly an 'unordered collection' that is iterable but does NOT have the "volatility" property under discussion.