Nominal types are really a compile time only thing: if you have two structs (or classes) with the exact same fields, I'd expect them to be stored the same way in memory. And as a result I'd expect any function to work on them just fine, as long as they find semantically valid data at the right offsets.
The purpose of TypeScript is to provide static types to JavaScript without just turning it into a compile target. TypeScript type system is only confusing because it's modeling real-life ultimately type-less JavaScript code. It's not it's own language with it's own rules -- it lives and dies as JavaScript.
> Types should not be a complex thing with a steep learning curve.
Types can be as simple or complex as needed. Assembler and C have very simple type systems with very few features and can only model very simple situations. Types in TS don't have to be complicated -- blame JavaScript programmers for their crazy designs.
That's not good. A type system should be crystal clear, predictable and reliable.
> and given the learning curve
Types should not be a complex thing with a steep learning curve. If you know Assembler and C it's pretty clear what types are about. Added complexity to your codebase is what you should try to avoid at all times. We have a limited capacity of things we can think of at a time, developers should therefore focus on things that really matter. In my daily work I see highly complex piles of spaghetti in TS that are 'type safe' and easy to refactor..