As far as I can remember, Flex1 was a "server". This (I suppose)was an excuse for the outrageous price. Users would upload their MXML and AS files, then the server would spit out '.swf' files to client requests. A compiled swf was cached until new MXML or AS files were uploaded. It was a "one licence" per company approach, rather than one licence per developer one.
Flex 1.x was a joke, but Flex Builder 2.0 was only $500. Making the Flex SDK (but not the IDE) open appears to be a case of openwashing, since most Flex developers are probably still buying the IDE.
by "supporting" other languages they mean they can compile the interpreter's c/c++ source code using their LLVM->actionscript bridge (http://blog.digitalbackcountry.com/?p=1095) they came up with and then run the script on top of that actionscriptified interpreter.
which, even for people like me who drink the interpreted-languages-are-fast-enough koolaid, seems like a lot of levels of indirection :) i think the CLR approach seems a little more straightforward: "native" interpreters that compile e.g. python->the CLR IL (instead of python->interpreter c source->llvm->actionscript).
and i doubt you could just take e.g. the python interpreter and throw it into a SWF -- certainly pieces of the interpreter along with C modules that interact with the filesystem, etc. would need to be tweaked to deal with the AIR runtime.
cool idea though, and they even got quake 1 (!) running in a SWF (see the video below in this thread... wild stuff)
If so, this is a good example of competition "waking-up" age-old platforms (like Flash).