Typescript is a dynamic language. Without changing the language, there is fundamentaly no way to resolve at compile time decisions that can be made only at runtime (ie, they are data driven). Monomorphization helps pin down (some) dynamic types but the fundamental problem remains.
You can compile two versions, it's not a big deal. "Fundamentally no way" means you're trying to solve math proofs instead of going for practical speedups.
But this case I think they do know the number type for sure, they're just failing to optimize around that fact.
Why don't JITs preserve previous work across runs of the same code?
If you encounter code with the same hash as last time, load up the previously generated binary and run that... or is that already happening?
Julia?
That's a JIT. Yes, you can do all sorts of optimizations in a JIT, because you do it at runtime using runtime information, and always keeping an escape hatch, so the static code bails when invoked with data it was not compiled to handle. This kind of hatch is used here with <any> wrapping.
JIT is a technique to accelerate dynamic languages at runtime to near machine performance while keeping dynamic ergonomics; but it can't transcend the AOT / runtime wall.
Julia sits somewhere between jit and aot, there is no interpreter part, if something is to be exectued, it's compiled to machine code.
The point is that you can have dynamic language that executes natively.
You can also compile whole program aot in Julia.