ENIGMA Development Environment

I think Ism's idea is better than Josh's, not to mention that systems like SVN/HG/etc will interface better with it.

Some languages allow post-fix types, such as ActionScript.

var x : int = 2;

What about this possibility?
Basically, every single local/global declaration rule would be the same as GM's, except for an optional suffix. This doesn't seem to conflict with GM's way, although I'm not sure I understood the problem.

C# has delegates, which are basically closures and definitively useful. First class functions are among the greatest innovations in programming in a long time. Saying they are useless is basically like saying object orientation is useless(although the arguments are different, the core point is the same). It is not a coincidence that languages that didn't have them are adding them now.
And Java has ugly closures. One of the most requested features for Java 7 was proper closure support in the syntax.

Funny fact about VMs. Some VMs allow AOT. So why not love VMs? They simplify the code generation step and generating bytecode(just like generating machine code) is faster than generating+compiling C++ code.
Pretty soon, your big projects are going to take hours to compile.

Even if you can't prevent it, C++ already provides decent protection.
I mean, Game Maker games were decompiled because they were ridiculously badly protected. I mean, COMMENTS in decompiled code!!?

Let's look at the facts:
1. Compiled games have no comments
2. A significant portion of the names used in ENIGMA will be gone, namely local variables.
3. The code formatting is gone forever

So indeed, the *code* is protected. And if huge-scale proprietary games have their resources unprotected(technically, they're impossible to protect), why bother to protect them in ENIGMA?
Also, if the infringer is in the USA, you can always use DMCA to prevent decompilation.

All that matters for the compiled version is not the type, but rather the *size* of the type.
So, if "weirdstruct" and "long long" happen to have the same size, the compiled version does not distinguish both.
An important exception to this rule is double vs int, which happen to have different assembly instructions(opcodes) and registers on some platforms, so in this case compiled code makes a distinction. Even then, only opcodes and registers differ. It can be really hard to figure out the original type of something. typedefs in particular are pretty much like #define.

Does GM really store a sprite per char on the exe?
I'd say it would be much more likely to just generate that sprite on runtime, considering that both the font name and the text can be variable, and that generating whole lines at once would be much more efficient, in my opinion.

Windows does allow multiple GL contexts in the same process. I've used that in the past.

The GL would be drawed in an invisible window. That's what I'm suggesting. Unfortunately, some "optimizations" may render this code useless, so I guess you'd have to try to know if it works.

Also, Cairo is either software-based or deals with hardware way better than most of us would be able to. Since Firefox/Gecko and GTK+ Webkit use it, I'd guess it was rather stable. I've had no reason to complain. So Cairo "context from somewhere" should *just work*. I don't remember how is one supposed to deal with GL interoperability, but it is possible(I've seen it done somewhere). Not sure about Cairo/DX integration, but I'm guessing DX doesn't have this problem. (Vista and later also happen to have Direct2D)

DX9 is used in XP. DX10 is used in Vista. DX11 is used in 7. Although DX11 has been backported to Vista.
DX10 is supposed to be far superior to DX9, but it doesn't work on XP which most Windows users are still in.