Also, i wonder if the external Carrier API should have a way to wrap an existing record class to see it as a Carrier, so the destructuring pattern will behave the same way with a record or with the result of a de-constructor.
Having records be their own carrier is an optimization we anticipate wanting to make, but I don’t think it is needed for Carrier to be involved in the deception. We’ll need a higher-level representation of a pattern (e.g., PatternHandle), which will exposes MHs for “try to match, return a carrier if it matches” and MHs for deconstructing the carrier. A PH could use the record itself as the carrier, and the record’s accessor MHs as the component accessors, and not use Carrier at all, and the PH client can’t tell the difference. So Carrier here is intended to be the lowest level of the stack; a building block for aggregating tuples, nothing more. We can then build pattern matching atop that (which can use Carrier or not, as it sees fit) and switch dispatch atop that.
