The one interesting thing here is that if you rewrite the execution environment, without creating a new language, you should be able to use the old code as tests for the functionality of your new code. You need some way to set up and tear down state for the snippets you're going to be executing, so the old execution environment that ran the system in production probably won't be suitable. Your best hope would probably be starting with a new "implementation" that can parse the code and either interpret it, or compile it, while recording the things that may be of interest to you (for example, if the old language was dynamic, and you need type information either for the purpose of documentation, or to generate static types for the new implementation, you can recover it by tracing).
You can't really use old code as a spec if you lack the necessary tools. Or, perhaps you could, but you'd be doing in your head what a computer should be able to do for you automatically. Expect working very long hours if you're so intent on doing a compiler's and code analyzer's work yourself.
It's utterly useless for data integrity -- imagine a database where every field is a string. There are no numeric fields...and what happens? Oh.
Somehow I don't think a computer system should have a problem with this. Ultimately, in every computer system, every field in a database is an 8-bit string. On some kind of disk.
Dumbass, you bicycle when temps are over 100
when temps are over 100
Also, e-bikes decrease your workload.