Industry Standard
Please understand that any mention of "Industry Standard" does a disservice to Construct here. The industry standard in game engines is to remove as many obstacles as possible when it comes to making our games (by being able to extend the engine capabilities for example) and to support and endorse third-party developers. Regarding vanilla features, there is also much to say about the industry standard: for example, the industry standard is to provide some in-editor tools to create UI for our games.
Encapsulation
Regarding encapsulation, perhaps indeed, many tools are doing that. But you must realize that popular engines were often designed from the start to provide a vast set of APIs. Because in those engines, the exposed API are used to develop many vanilla features (while again C3 vanilla features don't and won't use SDK2 but the SDK1...)
Even worse : most of the other engines mentioned here offer significantly more power thanks to their exposed APIs than what the undocumented features of the C3 runtime have allowed us to do until now
That's right: being able to access 100% of the undocumented features of C3 Runtime/SDK1 is still not as powerful as the publicly exposed APIs of other game engines that do encapsulation. So what about SDK2, which only exposes 1 or 2% of it?
Given the fact that you're such a small team with limited resources and you have no time to implement popular community suggestions requested for 5-6 years + the track record of rejected suggestions for exposing existing hidden APIs for both the Runtime and the Editor (which sometimes would take a few seconds/minutes) + the overall lack of acknowledgment from Scirra about the issues we're facing in our production:
How could anyone believe we will still be able to do anything relevant with addons once SDK2 is enforced as the only way to extend the engine ? The current process is already incredibly tedious and painful using 100% of C3 power.
It looks like the balance that existed with SDK1/Undocumented feature wasn't perfect but at least it was a good compromise
"Group Handler" addon
This is a perfect example of what won't be achievable at all soon, and how small the compatibility break issue was before all of this SDK2 madness started. The plugin is 6 years old, totally based on undocumented features, and still works perfectly and would probably keep working as long as Construct exists since the Event Group feature will never be deprecated. (Worst case scenario, a method would have to be renamed in a few years, that's all.)
This WackyToaster plugin inspired me to create a similar Group Management addon with different features to make it more modular and usable for large games, and it allowed me to solve several major performance issues that I had with my game. Soon it will just be impossible to do that, and my game performance will suffer a lot.
I made a bunch of private addons that use at least some undocumented features, but those features are used extensively by the C3 codebase and are very unlikely to ever change (I never had to fix any of them since I started making addons). These addons allowed me to solve all the performance and usability issues I was facing when making my Roguelike game using Construct. They also allowed me to get rid of some systems that required 500+ events (unreadable/impossible to maintain) and involved a bunch of weird tricks and workaround, or to overcome many limitations such as the lack of modularity in many aspects of C3 or things that are just 100% impossible to achieve with vanilla stuff.
>>> This is why I really think you should let advanced users access undocumented features forever at their own risk if they enable the hidden Developer Mode. <<<
^ This would be the perfect solution and would solve the issues for Scirra + Addondevs + Gamedevs users, for the reasons i explained in my previous posts : SDK2 would be the default way of doing things, and most of the users would only use SDK2 addons, but powerusers/complex game productions can still use C3 to make their games with the help of SDK1/C3Runtime (because the alternative is that we're forced to use an other engine to make those games)
Overall the C3 runtime code (SDK1 + undocumented features) is just far more pleasant to use than SDK2/Scripting interfaces, because SDK1 is used across the whole C3 codebase, as Scirra itself is using it to make any features of the engine, it provides a bunch of handy things that are useful to create new stuff.
SDK2/ScriptingInterfaces on the other hand, is incredibly limited because it's not written by someone who will actually have to use it to create relevant stuff, it's incredibly verbose and the APIS often assume way too much about how the user might want to use them, there is many situations were it does way too much things under the hood VS what i actually wanted to do, so it's sometimes not performant enough for no reason.
Also Scripting interfaces have been here for 4+ years and they still lack a bunch of obvious APIS, so SDK2 isn't even on par with the most basic stuff we could find in the already very limited documented features of the SDK1
Among the many many obvious things missing in SDK2 : what about all the methods to manipulate the SOL/picking of an ObjectType in the current eventblock ?
Even if in several years, the SDK2 implements enough APIS to port the publicly released SDK1 addons that already exists (such as Spriter/Spine/ProUI among many other), with a time-consuming and tedious dialogue between Scirra who have no time for this, and addon dev who have no time for this either, arguing for days/weeks for every single missing APIS :
What about all the private addons that were made for ambitious productions ?
What about the wasted potential of all the addons that could have been created and largely enhance the capabilities of C3 in the same spirit as 3DObject/ProUI/Spriter/Spine ?