Maybe consistency is the wrong term for me to use... maybe discoverability is closer to what I had in mind? Here's the scenario. Say this proposal is accepted with the rule that "an internal case with a Never payload behaves like any other internal case for pattern-matching; you still need a default to handle it." Say a developer doesn't know about this proposal and they see a generated interface in the Xcode UI with an internal case reserved(Never) for an enum in a library without library evolution enabled. They might get confused: "if this payload is of type Never, then why am I getting a non-exhaustivity error? Shouldn't that case be ignored for pattern matching similar to how it used to work before (when non-public cases weren't implemented)?"
The first thing someone might try there is they try to create an enum with an internal case locally (i.e. test it within the same module or say inside a Playground). If they do that, they'll notice that pattern matching on such an enum indeed doesn't require using default. This is even more puzzling. Why is there a difference when importing this module compared to using this feature locally? After some thinking, they might go look for a blog post, or the Swift evolution proposal, or they might realize that maybe there's a difference because of things being in different modules and create a multi-module minimal example to try it out.
There's this chain of reasoning they need to follow from "It's my first time seeing this new feature, huh, what's this" to "oh, I understand how this works."
In contrast, if we adopted a different solution to that problem, such as say an attribute like @nonExhaustive, then that's likely a much clearer signal "maybe it's this new attribute affecting things, let me look it up" and they can quickly figure things out.
Could you please take a look at my earlier comment? I've described 3 reasons for why I think extending enums isn't the way to go for this particular issue: it doesn't offer the desired semantics, it is a more complex feature to design and implement and it wouldn't offer the same ergonomics for solving the issues this pitch aims to solve.