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