I've certainly a more runtime oriented approach, everything the runtime needs to link in order to perform pattern matching are what i call pattern methods.
So, there's really three layers here: the language model, the runtime model, and the translation scheme. From a runtime perspective, deconstructors can translate to static methods (we don't need a new VM concept for this.) We need to keep our eye on the translation and runtime model, but I'm pretty confident we have multiple efficient translation schemes available to us, so I'm focused right now on the language model. Things like "deconstructors are total" can (like checked exceptions) be a language fiction that is erased away in translation, if we like.
for records, the compact deconstructor doesn't have to specify the bindings because they can be derived from the declaration.
Not so fast! Yes, for a record _without an explicit canonical deconstructor_, we can derive a canonical deconstructor which delegates to getters (just as we can derive a canonical constructor.) But, just as you can "override" the canonical constructor with your own (subject to rules), users should be able to similarly "override" the canonical deconstructor.
Of course, by that time, there will exist records in the wild without deconstructors, so we have a compatibility challenge. One way to resolve that challenge is to indirect the lookup through indy/condy, so that we can reflectively look at the record class and see if it has an appropriate member, or whether we have to synthesize one.
