This might be related to SR-11212, but reading the defect, I still don't understand the problem this warning is trying to prevent. (But it's not clear this is the same issue, since the whole point here is that I'm not splatting the tuple.)

Sorry about the poor diagnostic.

That said, this warning has been improved on master. a98d20f

If I run this example with the master compiler, it gives me the following diagnostic:

Tmp.swift:7:24: warning: enum case 'loading' has 3 associated values; matching them as a tuple is deprecated
    case let (.loading(lhs), .loading(rhs)):
                       ^
Tmp.swift:2:8: note: 'loading(mediaList:startingTrack:autoPlay:)' declared here
  case loading(mediaList: Int, startingTrack: Int, autoPlay: Int)
       ^
Tmp.swift:7:39: warning: enum case 'loading' has 3 associated values; matching them as a tuple is deprecated
    case let (.loading(lhs), .loading(rhs)):
                                      ^
Tmp.swift:2:8: note: 'loading(mediaList:startingTrack:autoPlay:)' declared here
  case loading(mediaList: Int, startingTrack: Int, autoPlay: Int)

> This might be related to SR-11212

Yes it is related.

> I still don't understand the problem this warning is trying to prevent.

The problem with the old behavior is that (1) it cannot be made to work consistently in the presence of nested patterns (a user ran into this in SR-11160) and (2) it is an oversight in SE-0110, patterns should behave analogous to function arguments – there is a difference between an enum case which has 1 associated value which is a tuple of N elements and an enum case which has N associated values.

> Given that the default behavior seems to be exactly as desired, this warning needs to explain why I should write so much highly-fragile code instead

I agree that for this particular case, the behavior is convenient and there is not much that can go wrong.

However in the general case, the old behavior makes it unpredictable what should/should not work. The table in SR-11212 shows four cases where the compiler's behavior was not what one would predict before the fix.

Marking this as resolved for now (since we have improved the warning), but please feel free to unresolve it if you feel like something is unclear or you feel that this should not be a warning (in the latter case, maybe we can have a discussion on the Swift forum or somewhere else).

Fixed on master.