Well, HaXe can use pre-compiled code, since maybe more then a year ago I guess... It doesn't use SWC, but ans SWF as an input is OK. Probably Niel can elaborate on that, or correct me if I'm wrong.
HaXe has a way to deal with AS3 global functions (for example you could've exposed them through Lib class), I don't think it would be particularly difficult to add a compiler macros to handle the declaration of such functions too, when working particularly on AS3 target. I never found any practical use case that justified the use of internal or custom namespaces except for some side effects, like, for example, providing access to a function if the code asking for the access is authorized to do it. Which was still a nice, but useless trick. I could never be confident whether to use protected or private because I really view them as the same thing. I really think that separation of these two added more complication, where it wasn't actually needed. I see the absence of E4X as a good thing, it has proved to be both very difficult for understanding and inefficient, especially as implemented in ASC/MXMLC. It is both difficult for the user to write, for the compiler to optimize and for the editor to highlight it properly. Besides, the instances of framework code using E4X can be counted on the fingers of one hand, so it's not really an issue. In my opinion, the framework in any case requires a very fundamental rewrite. The way things were done wasn't good, but no one took the courage to change that because of number of promises Adobe had to keep to the people who used the framework. Why not use MXMLC? - obviously, Adobe aren't going to support it, unless for maybe critical fixes, so if you are going to support it, you are quite on your own with that. MXMLC, as a program, suffers from all kinds of architecture errors and this is probably the reason Adobe decided to not to fix it, but develop something new. When I used Metaas, I used it because me and my friend where trying to do something like real-time code-behind generation for MXML files. I.e. we were working on a plugin for FlashDevelop that would compile MXML files as you edit them and, if you wanted to, you could switch to see the source produced by MXMLC. While doing this, I got acquainted with MXMLC source code more closely, and, honestly, it's a mess... After some time of trying to do what we wanted with MXMLC, we decided to patch Metaas to do the codegeneration, because it seemed to be easier and much more generic! We actually succeeded to a degree the prototype was working :) But then we got both frustrated about MXML as a concept and never touched that thing again. Best. wvxvw
