(Raising the priority to "high" because any decision on this should ideally be made before the 3.10 RCs.)

Hm, interesting. This is because we use UNPACK_EX for these patterns, so the destructuring is basically the same as if you had written:

[x, *w, y] = Seq()

...which also hangs.

We actually have three implementations for destructuring sequences:
- Using UNPACK_EX, when there is a starred name.
- Using BINARY_SUBSCR, when there is a starred wildcard.
- Using UNPACK_SEQUENCE, when there is no star.

When using your Seq class:
- The first fails by falling into an infinite loop.
- The second works as expected.
- The third fails with a ValueError at runtime (for a length mismatch).

*If* we decide that this is a big enough problem to fix, then I think the easiest way of doing it is to use the BINARY_SUBSCR implementation for all three paths (we'll just also need to use BUILD_LIST / LIST_APPEND to actually collect the starred items). It will simplify the pattern compiler a bit, but I imagine it will also come with a performance penalty as well.

In my opinion, I don't think we should rewrite everything to support Seq (though my mind isn't made up entirely). Sequences are supposed to be sized and iterable, but Seq doesn't really support the iteration protocol correctly (it expects the iterating code to stop once the length is exhausted, rather than raising StopIteration).

I'm curious to hear opinions on whether we want to actually fix this, though. It seems that it will always be possible to write classes like Seq the hack our pattern-matching implementation with dubious sequences and mappings, so it really comes down to: is supporting classes like Seq worth potentially slowing down all other sequence patterns?