Your comment seems like a non-sequitur. What does pattern matching have to do with runtimes?
Isn't one part of pattern matching to ask for a type and the other to ask which values the (instance?) of that type holds?
When a language has algebraic data types -- i.e., data types that have multiple, disjoint constructors -- pattern matching generally means determining which constructor was used to create the value being matched, and branching on that. I'm guessing this is the kind of pattern-match that TypeScript users would be eager to have.
What I don't see is how this requires the addition of a "runtime" on top of the JS model to make it work. I don't use TypeScript, and don't know how it implements its data types, so there may be something obvious here that I'm missing.
Pattern matching doesn't require any kind of runtime support, and can be implemented through desugaring.
Why would it need runtime support? It would just desugar into an if-else chain.
I believe there was/is a stage 0 proposal for pattern matching in ECMAScript
This trade off is good because there is no runtime overhead, only desugaring. Typescript should never become ML or anything else that Javascript is not. If you want pattern matching in Typescript you need to convince the Ecma committee to put pattern matching into Javascript first.