Without being facetious[1] if you don't care about performance, you don't need a set, you could use a list.

Lists don't enforce uniqueness.  Apart from that a list would probably work fine for my needs; in my admittedly-modest workloads I would probably never notice a performance difference.  My anecdote was merely a jumping-off point for the discussion.

"I don't care about performance" is not because I'm aching for Python to run my code slowly.  It's because I'm 100% confident that the Python community will lovingly optimize the implementation.  So when I have my language designer hat on, I really don't concern myself with performance.  As I thought I said earlier in the thread, I think we should figure out the semantics we want first, and then we figure out how to make it fast.

I'll also cop to "a foolish consistency is the hobgoblin of little minds".  I lack this strongly mathematical view of sets others have espoused; instead I view them more like "dicts without values".  I'm therefore disgruntled by this inconsistency between what are I see as closely related data structures, and it makes sense to me that they'd maintain their insertion order the same way that dictionaries now do.

/arry