That said...
I've learned that "library" types might not be the best way to talk about these concepts. What we're really talking about here are types that are complex/advanced enough to force you to venture beyond the primitive building blocs in the TS docs and into existing open source solutions that have trail-blazed more advanced use-cases. It took me only a few weeks to get comfortable with common TS, but at least a year to feel dangerous enough to write more advanced TS. I'm on year 3 now and I am still learning/forgetting so much about it.
I agree that: - Advanced types and their concepts are difficult to learn. - There is limited documentation on how to create/use them. - They can sometimes be difficult to reason about, mainly due to the limited syntax TS offers around advanced concepts.
On the the positive: - They can be learned with practice. - There is plenty of OSS out there to learn from - Once you learn them, you start to think differently about TS as a language instead of annotations
I wish there were better features/syntax support for: - Optional generics - Higher-order generics / Polymorphic generics (basically higher-order functions, but for types) - More built-ins (like ts-toolbelt, type-fest, etc)
I think this ramp of difficulty with advanced TS types is fine for the most part. Library authors have always carried way more of a burden than devs at the edge, even during runtime to ensure things like size, performance, flexibility, etc. TS is just another facet that is becoming more an expectation every day.
At the end of the day, a library dev gets to choose what level of investment they'll put into great types for their library. If they can pull it off, their tool will likely provide a measurably better developer experience.
That's my goal for my libraries, so choosing to go all-in on advanced TS is now a no-brainer.
Anywho, good luck!