>>64
I am not quite following your argument but I'll try.
The obvious example is asm.js. It accepts Javascript, does meaningful type-level analysis on it and interprets it differently if the code meets certain conditions.
In general though, analysis only begins at the type level, and you will need to unify types and reject improperly typed languages. Many static languages do this in their compilers, then proceed to erase the types entirely. But that isn't strictly where type theory ends, the programmer can write their own constraints and dispatch (eg. ADTs &c. but you don't need anything fancier than conditionals or computed jumps.)
So once you've gotten the compiler-recognized types unified according to the type system, you're left with the same problem as in dynamic languages: figuring out the second system.
Static types will give you a cheap advantage in analysis. You can express powerful semantics with the right type system. But you can express only lies with weak ones like C's. BCPL's is more honest and unityped.
What I'm saying is in general, you can't count on a static type system to tell you enough to do meaningful analysis on types alone, and once you get past the types, you have the same problem as with dynamic languages. Even if the types can provide enough information, the is no guarantee that the code is written to take advantage of that property.
The downward spiral is a program in any language can be written to be completely opaque to any particular means of analysis. You have to pick your target.