> So essentially Typescript is importing JavaScript's already onerous dependency situation putting another set of dependencies on top of it without any formal correctness guarantees or automated compatiblity checks.
An increasing number of JS libraries on npm maintain and provide their own Typescript definitions, so the ecosystem is getting better and in some cases there are no additional type information dependencies beyond your JS library dependencies.
> The language itself is under constant threat of breaking changes introduced by new JavaScript versions.
I've used Typescript in production software since around TS 1.0, and Typescript has been very adroit of working ahead of JS versions. The biggest change, and closest to a compatibility break, was that import/export syntax changed slightly to reflect ES module import/export syntax, and that wasn't entirely a breaking change (the old syntax still works, though is marked with a deprecation warning). On the other side there were ES2015 features I was happily using in Typescript years before ES2015 was finalized, and am happily using proposed features that are only Stage 2 or Stage 3 today in the standards process.
Ecma's TC39 is following a similar playbook to the rest of web standards and using an approach to where multiple implementations should be built before the proposal is accepted into the language. TC39 has the benefit that not only do they get browser implementations, but polyfills/prollyfills, Babel, and Typescript implementations to learn from in adopting a proposal.
Typescript very much is leading JS development as much as, if not more than, it is following.