I've explained how there are two paths: the industry-standard API approach, or things end in disaster. Here it sounds to me like you are arguing in favour of the way that ends in disaster. I'm afraid this type of thing is just very worrying to me: it represents a risk to our business, reputation, and customers. The fact you've already written code for your editor UI system using the unsupported approach - especially open source code that is beyond your control, allowing any other developer to pick it up and use it - indicates to me that you are still using the approach that ends in disaster. If you wish to propose a feature or prototype something, don't do it by using unsupported features - you can always write up a feature proposal, prototype things using supported features only if possible, or otherwise prototype them in a separate development project, or basically anything else at all except that. The very existence of code using unsupported features, particularly open source code, already poses a risk to us. This is a tough thing to say because addon developers do a great deal of good work for Construct and the ecosystem, and I believe the vast majority of addon developers are acting in good faith, but I'm afraid there is already a risk of a serious disaster from the work you've already done on the editor UI system. The prevalence of SDKv1 addons using unsupported features posed a similar risk, and we felt obliged to mitigate that, and I feel similarly obliged to mitigate the risk here. One of the ways I am trying to mitigate it is by as strongly as possible discouraging anyone from using the approach that ends in disaster.
Unfortunately having good intentions, or even accepting lower standards of reliability, does not change the situation: as I explained, it's us and our customers who suffer the disasters, and our reputation that is hit, while sometimes the addon developer responsible isn't even aware of what happened. Regular users expect stuff to just work, and it's our job to ensure that's the case. I would assert that it is also the job of addon developers to help ensure that's the case, and the way they do that is to stick to only the supported features. Encapsulation means that good practices are enforced rather than just hoped for. We know from SDKv1 merely hoping people do the right thing does not prevent disaster.
Using unsupported features may be fun, creative, helped some people to learn development, or whatever. I'm afraid that doesn't change things: it is not a professional way to develop software and the concept of encapsulation was invented to prevent it, because it inevitably ends in disaster. I care about software quality and ensuring paying customers have a good experience. If addons risk that for customers, I believe it's our job to fix that and do better for our customers. If other software sucks and constantly breaks things, then I aspire to do better with Construct. You can open Construct 2 projects that are well over a decade old and for the most part they should still open and run just fine in Construct 3. That's the kind of compatibility we aspire to (and was impossible to provide with SDKv1, but can now be provided with SDKv2). We don't have a perfect track record on that: there is a tension between making improvements that require breaking changes, or keeping backwards compatibility forever and the software ossifying and being surpassed by competitors. When we make breaking changes we carefully plan them and do what we can to mitigate the damage, including things like long phase-out periods with notifications. However where addons use unsupported features, it is impossible to plan for changes: breakage happens suddenly, unpredictably, and without any documentation or support, so the damage is much worse. Then lots of people blame us anyway, our reputation suffers, and a bunch of people go away thinking the staff at Scirra are both incompetent and irresponsible. If you are asking us to just put up with that so addon developers can have fun playing with internal unsupported parts of Construct, I'm afraid that's just too much to ask.
For what it's worth, if we did an SDKv3 with editor encapsulation, I believe we could do it preserving backwards compatibility for addons that only use the supported and documented APIs. We should not have to change the APIs themselves like we did with SDKv2. So - like any responsible addon developer should already do - stick to only the supported and documented features, and you'll probably be fine. If you ignore this advice and use unsupported features, most likely only those addons risk breakage with an SDKv3 - and that should not actually be surprising, as such addons risk breakage at any time anyway. So if you use unsupported features and accept it can break permanently at any time, presumably you can just consider new encapsulation features as just another possible cause of that. So perhaps that's fine then?