I haven't worked on the project in a long time, but we discussed all this stuff back in the day, so I thought I'd give my two cents on what we determined:
1) Windows phone compilation support - I can then make games for my phone, lol.
This is feasible. We've worked on iOS and android support. Windows phone would be the next step, but I think just getting iOS and android working again would be a higher priority, since they are easier.
2) Program compatibility with Windows phone - I want to work on my projects portably (Not desperate for this.)
This is unlikely. Even though LateralGM is written in Java, so technically it could work on any platform, it is targeted as a desktop application, with full mouse and keyboard support required. There are drag gestures and key-mouse combos and special key (like ctrl) frequently depended on throughout the application. If you want to develop on the go, get a laptop.
3) Multi-user online editing - I want to get my dev team working on this project, but it kinda makes it difficult that we have to pass the file around
over skype. (Again, I can just about cope without this)
This is planned. As Onpon said, the solution is to use a SCM (version control), such as Git. The issue that GM faces is that their file format is binary, which does not version/diff well; it works best with textual files. Fortunately, here at ENIGMA Corp, we've been researching and investigating textual technologies, and have come up with a few solutions. First and foremest, we have the EGM format (currently alpha). This format is designed to store every resource in its own textual file, called an E-Yaml file, with any data that is necessarily binary (such as images) stored separately. However, EGM is designed to get compressed, which just converts all the data back into binary again, but we have designed an uncompressed version so that you can use version control. Additionally, there was a project call LgmScm, which was a plugin for LateralGM the would port your code into an SCM-friendly format and add basic SCM integration (independent of whichever SCM system you chose). I don't recall whatever happened to it, but I'm sure it will get looked at again once EGM is more stable.
4) Improvement to Game Maker project compatability - Seriously, there are too many functions that I can't use on Enigma that I used to frequently
use on Game Maker (Eg: execute_file) (I am aware I can implement Lua into Enigma somehow to solve this, but I'm too lazy to read the
instructions all the way through)
So, the big hurdle here is that execute_file requires something able to parse and interpret said file and inject that code into the game. This is an issue because unlike GameMaker, ENIGMA is compiled, not interpreted. We convert your internal game code into C++ code and then send it off to the C++ compiler (gcc), once and done. This requires a full suite of tools installed on the developer's machine - mainly gcc. We can't expect players to have gcc, because they're not developers, and gcc is huge, so we can't just ship it with the game.
5) Fixed GEX support, or atleast implement it. (I see the feature is "there", but it doesn't function. Are you going to implement it, or not, lol.)
The issue with GEX is that it's often used for packaging a DLL with your game. DLLs are windows only. They are not cross-platform. Linux uses .SO files, and mac has I think a DYLIB. None of these formats are compatible (and for good reasons, since they often directly access things in the OS). We can workaround this a little bit by packaging a version for each in your GEX (so it will have all 3 - a dll, a so, and a dylib), which is more or less the plan. It'll still restrict the oparating systems that can play your game, or at least that can use the GEX extensions (so you may not be able to play your game at all on most mobile devices if it has a GEX), but it's better than no DLL support at all. It's also quite possible that we'll create our own GEX-like format, since GEX is property of GM, and if we had our own we could do more with it.
Anyways, thanks for the suggestions. They are great reminders to continue working on these side things that are often outside the scope of the main codebase.