Lets first cover how Blizzard initially broke JNGP, or more specifically, Grimoire which is what makes JNGP work. This happened already in version 1.22, when they decided to change compiler. To figure out why this is a problem, we'll take a look at how Grimoire works
exactly. This is the information stored for the ObjectId hack, the little box that pops up when you create a new object, which lets you set the id you want.
C:
const char NewObjectIdPattern[] = {
0x89,0x50,0x04,
0x89,0x08,
0xC7,0x43,0x24,0x01,0x00,0x00,0x00,
0x8B,0xC2,
0x5B,
0x8B,0xE5
};
const char NewObjectIdMask[] = {
0xFF,0xFF,0xFF,
0xFF,0xFF,
0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,
0xFF,0xFF,
0xFF,
0xFF,0xFF
};
Grimoire works by scanning the memory for patterns. The mask is included so some bytes can be wildcards. This isn't used in this case. So, for the ObjectId hack to work, it needs to be able to find
one match for the byte array in NewObjectIdPattern. As you can imagine, this approach is rather sensitive to changes in the source code, but if done correctly, it could theoretically be version agnostic for the most parts.
This wasn't the case when Blizzard changed the compiler. The change resulted in tiny, but breaking changes. Instead of using the EAX register, it might now use the EDI register. Nothing that would affect the editor, but it broke JNGP completely.
Newgen is nothing else but code injection and the integration of existing libraries like Jasshelper, Tesh, etc.
JassHelper relies on Grimoire to start it when the map saved. With Grimoire broken, this couldn't work anymore. TESH is a bit more lenient in this way. It simply detects when a window is created by hooking the windows API, and then overlays the existing editor with it's own functionality. It still has to be injected though, and with Grimoire dead, it wasn't going to happen.
It doesn't matter which editor version it is using, unless blizzard really adds new features to the editor which I highly doubt. The only thing we can expect in this regard might be a new native or two which can easily be added to Newgen by updating the .j files.
So now you can see, the version matters very much, which is why version 1.21 of WorldEdit.exe has been bundled with JNGP ever since.
Writing a Newgen from scratch is a monumental task. This is why WEX pretty much provides nothing of the functionality that Newgen does yet. You won't do this in a couple of weeks. People worked on Newgen for years to get it in the state it is now.
You're correct that the NewGen collection took a lot of time. It was only possible through the collaboration of dedicated people in the community. WEX is lacking, only because the tools created for JNGP are broken or outdated or haven't been deemed necessary yet. It's a process that takes time. The core functionality IS working. It can launch custom compilers, it can inject custom menus. It even comes with the object id hack, which was a royal pain to port.
Also, it's not a big deal for blizzard to support Newgen forever. [...]
So, yes Newgen IS future proof unless Blizzard really fucks something up like they did in 1.28.
By now you obviously know this isn't the case. A minor change in their code can break everything.
Also, blizzard clearly stated that they care about not breaking backwards compatibility to old maps. Guess what: almost all old maps were created with Newgen, so they kinda have to roll with it anyway.
Blizzard aren't responsible to making sure our third party parsers will continue to work. They're concerned with making the actual JASS work, without compromising security. And when they break things like order ids, they're going to fix it as soon as they can.