The main drawback, being total is not a __local__ property.
This is true, and we've talked about this from the beginning, but I also think that the fear of nonlocality here is pretty overblown. Yes, there are puzzlers, but they are mostly of the kind where `var` and "diamond" interact -- and the solution to those puzzlers is "add back some explicitness, so it's clear what is going on." The solution is not "let's cripple var so it doesn't interact with diamond", or "let's outlaw the interaction of var and diamond" or "let's not do var."
We proposed using totality not because its "clever", or because it makes a certain pesky problem go away, but because it is the most _natural_ way to unify the semantics of all the ways patterns are used, and this becomes obvious once you get to examples that actually use nested patterns. I think much of the reaction to this aspect is based on holding on to the existing model of switch/instanceof, which are both very limited right now. Once you see these as more general deconstruction operations, the role of totality immediately comes to the fore, because of the expanded range of problems we will see with conditional destructuring. So I think there's a lot of "judging the new feature by the use cases of the old feature." We may be reusing the syntax of instanceof and switch (for good reasons), but these are not the instanceof and switch you learned about in CS 101. Lets not hobble the new feature because the old version was insufficiently ambitious.
So this is far worst that re-organizing two cases in the switch because as a user you have done something. A pattern can be total or not depending if someone change the return type of the method you are switching on (this methods can be in another module) or change the class hierarchy (again, the hierarchy can be defined in another module), the code stay exactly the same but the semantics is changed.
Sorry, but I think this is mostly FUD. There are a zillion ways to leave information implicit: var, diamond, generic invocation, method chaining, method references (which pick an overloading), implicit lambdas, etc. And there are a zillion ways to construct puzzlers from code that does something implicit, where the answer would be obvious if we wrote out the fully explicit representation. And the same thing always happens when a new feature wants to join this club: "There exists a possible way someone could get confused by combining these ten features, so we must blame the last feature that came in the door!"
So, coming back to the main goal, our job here is first to find the _natural_ semantics of pattern matching. And every path I've gone down tells me that totality is part of the natural semantics. And I've not seen any credible arguments that suggest it is not -- just fear that, through interactions with other features, it might be too new, too complicated, too confusing, etc. But this happens with every new feature! We're used to (and have come to terms with) the OLD features interacting in possibly puzzling ways (e.g., var+diamond), but when a corner of a corner of a NEW feature threatens to do so, people declare "this entire new feature is broken."
More importantly, we want to have the right _global_ story. Proposing localized hacks to deal with the aspects you don't like is highly unlikely to bring us to the right global story.
