You can say you only change the semantics of switch not the semantics of pattern matching, but the idea that you can separate the two is confusing.
From a mathematical point of view, it is quite clear. We define a `x matches P` relation. In this relation, `Object o` matches all values of x, including null.
Then, we define the semantics of `instanceof` and `switch`. For example, `x instanceof P` means: "if x is null, then false, otherwise evaluates to `x matches P`." The construct gets to decide when to evaluate the pattern.
This is just like how we separate the inference machinery from how inference is used (differently) to produce a result for diamond or var.
What you're saying, I think, is that most users don't separate the layers like this; their understanding of pattern matching is conflated with how pattern contexts like switch/instanceof work. And that is surely true. But having a clear definition of how pattern matching works, and a clear definition of how switch/instanceof use pattern matching, allows the users who *do* want to understand, to do so more easily, because we've separated the concepts.
PS: the feedback about the fact that it's not clear if a switch allows null or not can also be seen as a symptom of the fact that the notion of total pattern is not obvious for everybody (and having no syntax hint does not help).
I think this is the real issue; leaning on totality is more sound and less ad-hoc, but harder to learn. You'd like to make that easier to learn by introducing more syntax; I'm saying that this is (a) more complicated in the long run, and (b) way over-rotating towards treatment of null.
