People provided you some solution to fix the main issue that you're raising and that we're trying to understand (basically protecting people from using risky 3rd party addons).
An other idea to solve this :
- The addon developer check a simple bool if the addon is considered as "risky".
- A pop-up warning saying "If you use [insert risky addons names] in your project, it could break your project in a future update and Scirra won't help you to fix the issues related to your 3rd party addons" with a link to a new documentation page explaining everything you explaind here. ( you could list a bunch of potential issues here such as the Android publishing requirements).
- The warning popup could have a button "make a backup" to let the user save an alternative c3p of his project before opening this.
- You could pop up that warning each time a project with a risky addon is updated to a newer version, and suggesting to open the last version the project was saved instead (so people could stick to this version)
This kind of thing would do the trick, there are actually easy solutions to the issue you keep mentionning. It just requires a bit of good will.
However what you're about to do WILL absolutely create a disaster. It could potentially break all the most advanced projects currently developped using C3 + thousands of more simple projects using 5 years of community work
It would be throwing off those 5-6 years of collective work, for litteraly no rewards for the community who put so much effort in it.
As C3 users and a community we know the long dark times Construct went through when it hurted its own powerusers / 3rd party devs with some decisions. At least, the last times there were clear benefits for us in the balance : Construct 2 => Construct 3, worker mode support, but those were still painful trade-offs.
How should we expect you to create a better Addon SDK (merging it with Scripting API) when we know getting obviously missing Addon SDK and Scripting API from you, related to already existing features is such a painful, time-consuming and hopeless process ?
Here is just one of the most recent example I personnaly experienced : github.com/Scirra/Construct-bugs/issues/7735
Skymen also wrote a blog post mentionning that exact issue 2 years ago : construct.net/en/blogs/skymen-13/flexbox-weird-characters-1590
(If anyone wants to know how bad an obfuscated Runtime would be, the part of the blogpost about the already obfuscated Editor API is insightful btw)
Also if 3rd party addon dev, relied on Scripting Interfaces, it would be even worse than the current limited Addon SDK in some ways because it would mean that we'll have to develop plugins and behavior TOTALLY differently than the way Scirra is developing vanilla addons.
Anyway C3 is moving in the opposite direction of Game Engine history here with the rise of Open Tech. (by that i mean having an Open Philosophy not necessarily Open Source)
A bunch of game engines/frameworks targeting web are growing pretty fast with a similar Open philosophy such as Defold or Phaser.
Game-maker very recently OPEN-SOURCED their runtime.
Godot has become the biggest Engine in term of itch releases, social media interaction, exponential growth of commercial releases and is relying on a Open philosophy letting devs customize their experience both at Edit and at Runtime. They probably have the most capable 2D engine and each Godot user has a guarantee to keep the full ownership of their own work indefinitely, no worries about unipersonal decision that could destroy years of work (+100% free, 100% open source). They are also planning to enhance their web exports a lot by providing options to reduce the build size and manage load times efficiently.
The 3rd party dev communities are big and prolific in all those engines, this is probably one of their biggest and most resilient strength.
From a gamedev perspective, C3 advantages over its competitor are already narrowing, and this single decision would makes things worse really fast.