So you may be right, it seems typescript will still be around for enterprise at least.
I don't think I follow what you mean here, can you clarify?
In a world where JS has type notation, we'd need a similar command that could analyze the code without running it.
If I could avoid that step and still have type annotations and tooling support, I would be a happier person.
Don't make a type system work around the really bad parts of JS. Instead, don't allow them in typed modules. Don't settle for an intentionally unsound (aka broken ) type system. Add an actually sound (probably hindley-milner based) type system that provides usable type info to the JIT so we can guarantee fast, safe code.
It makes much more sense to use a good language (Kotlin, Rust, Java) and transpile to JavaScript. There's already great tooling for it.
1) TypeScript supports a huge set of syntax for describing types, and I would be surprised if the standard ever supports all or even most of that, which would mean you can't skip the build step for most real-world TS projects
2) Most front-end projects will continue to have a build step anyway because of things like JSX, minification, and bundling. And if you've got a build step already, stripping out types is one of the easier things to do as a part of it (and you would want to do it even with this proposal, as a part of minification)
3) On the back-end Deno and Bun run TypeScript natively without a build step. Node doesn't, and it won't be displaced overnight, and it may end up the biggest beneficiary of such a proposal. But even there, build tools like esbuild are fast and easy enough to use that you don't gain much by being able to avoid them (and if you're benefitting from static checking, you're setting up at least one tool already!)
I won't go so far as to say it's a bad thing, but I think it'll end up one of those standards that nobody really uses