In that case, i prefer the current semantics because it's the same if a pattern is a top-level or not.
I wish people could keep these things straight. We’re not talking about changing the semantics of how pattern matching works, which patterns match what, what nesting means, etc. We’re simply talking about the *boundary* between a specific pattern-accepting construct, which has pre-existing value filtering opinions, and the patterns it accepts. The current (preview) boundary says: - If a switch has a `case null`, or a total pattern, a null value matches that, otherwise we throw NPE on null, and for non-null, it is matched to the patterns in the case labels. The adjusted boundary says: - If a switch has a `case null`, a null value matches that, otherwise we throw NPE on null, and for non-null, it is matched to the patterns in the case label. So this adjusts *which* patterns the switch lets see null values. Previously, it was “none”; in the current preview, it is “case null and total patterns”, and the adjustment proposed is “case null”. The latter is a tradeoff to avoid confusing the users, who currently believe switch always throws on null, by saying “switch accepts null if it says case null.” We currently have a similar problem with `intsnaceof`, where we disallow total patterns on the RHS of instanceof. We would adjust in the same way: instanceof always says false on nulls, and tests against the RHS on non-null. Nothing to do with the semantics of pattern matching. Total patterns are still total.
