The problem is not at callee site, as you said you have deconstructor binding like you have constructor parameter, the problem is at callsite, when you have a Type Pattern, a type pattern does not declare a type that can be used at compile time but a class that is used at runtime (to do the instanceof). So the problem is not how to declare several deconstructors, it's how to select the right one without type information.
Overload selection works largely the same as it does with constructors, just with some of of the “arrows reversed”. But I think you’re extrapolating from deconstructors too much, which are a very constrained kind of declared pattern. A pattern combines an applicability test (does the target match the pattern), zero or more conditional extractions (operations performed on the target only when it is known to match), and creation of variables to receive the extracted data. For a deconstruction pattern, the applicability test is highly constrained — it is a class-based instanceof test, and the language knows it. If its of the right type, the deconstruction must succeed — it is *total* on that type. But this is a very special case (and a very useful case, which is why we are doing them first.) Consider a more complex situation, such as querying whether a regex matches a string, and if so, extracting the groups. Here, we can use whatever state we like as our match criteria; we are not constrained to work only with runtime classes. More importantly, the code to determine the match and extract the parameters is completed; if we exposed this as a boolean-returning method (“does it match”), we’d have to do all the work over again when we go to extract the groups (its like containsKey and get in Map.) This is why the current regex implementation returns a stateful matcher object. Class-based matching is just the easy case. nope, because if we have a type pattern / record pattern we have no type information. If named pattern method allows overloading, we will have the same issue, there is not enough type information at callsite. I’m not following this argument. Can you try to write out some end-to-end examples where you say what you are trying to accomplish? By simpler model, i mean we do not have to mirror all the method call quirks as patterns, only the ones that make sense from a "data oriented design" POV. OK, but all your arguments are “against” — you just keep saying “we’re doing it wrong, w can make it simpler.” You haven’t outline *how* it can be simpler, or what problems you are actually worried about. Which makes them pretty hard to understand, or respond to.
