TorqueScript or game scripting in general

#1 Data typing, large number precision, and speed improvements.

If replacing with another language for scripting I would wish for C#

#2 Large number, as in 64-bit? or larger?

[EDIT]
Reason I ask is that numbers, once they get so large are really scientific and need a library to do calculations on them, etc. I wouldn't think "scientifically" large numbers are needed but hey, I'm not everyone out there.
[/EDIT]

#3 I've always been generally confused about the different scripting languages as a whole and cannot for the life of me figure out what makes one scripting language better than another. They all run externally to whatever you are using them on meaning that they are nothing more than an interface to a black box, sending a message in and getting a message out for the most part.

everyone seems to have a favourite scripting language based on their favourite syntax, my past commercial experience was using vbscript for asp websites, so to such an extent i'm used to slackass variables that can be anything they want to be (tho there were options to reign them in that i think should exist here... they dont exist right, havent been added while i wasnt looking?).

I'm also semi interested in how torquescript itself could be improved, as i think i stated earlier, i'm confused a lot of the time and as such not an expert. But it does seem to me that any and all variables being basically strings must be slower than other types, especially when dealing with simple integer arrays? no?

I guess we have an advantage over some game scripters in that we can ourselves convert any scripts that require any intensity of processing into engine code directly (tho personally this has led to headaches and flying cats when i try)

#4 Actually that's why I'm asking. I'm almost done w/ a rewrite for the VM and torquescript.. The one thing I was going to add though, on top of the VM change, was the ability to use different "languages" on the front end and allow interoperability between them. This is a completely different implementation than what's in the engine; I mean completely. I'm not going to say much more about the optimizations at this point, but they are close to the "speed" of binary code, and if it stays the way I have it right now, should be enough. Running some major testing on it for now just to ensure nothing is broken. Also, just to clarify, it's not a cross compilation of different language engine's themselves. It's more like the ability to use that languages syntax and operations, etc.

#5 I don't think I would change much to be honest ; scripts should remain scripts: quick and easy to write, something designers can understand and use without caring too much about case sensitiveness and strict data typing, etc.

If the logic we're trying to write requires more complex mechanics, I'll just add what I need on the C++ side, and expose some new simple commands and functions for the scripts to use.

Nevertheless, if there was one thing I'd like, that would be better (real?) support for arrays ! That'd help a lot in some cases.

Otherwise, I really like how easy it is to "generate" script code dynamically (i.e. concatenate bits of strings, variables, data, etc. to generate new script commands that can be eval()-ed.). As long as I use some kind of naming convention for the elements I want to access/control, this really helps to automate a lot of things.

#6 Array's have been noted and added on this version. I'm not changing how dynamic the script code is or that it's auto generated, etc. It's still a script. Just speeding things up and adding where needed.