I'm not aware of any particular reason the SDKv2 cannot support Mikal's 3D object. In fact, in the latest release we just added a new drawMesh() API to improve the performance and ease of use of rendering content like 3D meshes.
Why not allow SDK1 in a “Legacy Mode” for non-breaking use-cases?
This has all been discussed extensively already, but to summarize: if we leave it there, people will just continue using it, and compatibility disasters will keep happening. The only way to stop the on-going compatibility disasters is to remove SDKv1. Besides, arguably the LTS release is that "legacy mode" anyway, as that's your option for continued SDKv1 support.
Why drop NW.js so abruptly when it’s the main route for native integration with platforms like Steam?
This is a different topic, but we have our own desktop export options for Windows, macOS and Linux now, and it's time to move over to those.
locking advanced users into a frozen version until end of 2026 feels like a temporary band-aid — not a solution.
Actually I would say what we are doing is a permanent solution. Other options like continuing support for SDKv1 would be temporary band-aid solutions that still end up causing problems.
Could we get official support for a compatibility layer, or at least some guidance for rewriting complex plugins into SDK2?
I'm afraid a compatibility layer is not feasible. However we have long had our guide on porting to Addon SDK v2, plus a set of sample addons, including links to the git commits showing the changes made to update from SDKv1 to SDKv2.
Could Mikal or other devs collaborate with the Construct team to extend SDK2 to support the missing functionality?
We've done a fair bit of work on this already. We announced SDKv2 a year ago and have been making various updates to it since then. You can see a log of past SDK updates here, and there's other things like support for the aforementioned drawMesh() API that have come about in large part from discussions with addon developers.
Removing SDK1 may reduce technical risk, but it creates a community trust risk.
To me we already have a community trust risk with SDKv1: I can merely rename something, move some code, or fix a bug, and suddenly some SDKv1 addons are broken, and in some cases the addon developer has left the community. Then people see their project break in some Construct update, and they all contact support and tell us our latest release is broken and we need to fix it. If we try to explain about it actually being the addon developer's fault, in some cases people actually refuse to accept that, interpret us as shirking responsibility and trying to shift blame on to others, and they only get more angry and insistent that we fix our broken release. It's a miserable situation, it really sucks, and nobody who cares about making software that works actually develops this way: this is thoroughly understood stuff in the industry, encapsulation was invented decades ago to solve precisely these problems, and the only reason we didn't use it previously was that historically JavaScript didn't support encapsulation. But now it does and we can fix the problem.
I'd add that back with SDKv1 we always knew the lack of encapsulation was a risk, and so we also had a big red warning in our SDK documentation saying "don't use undocumented features". Our latest documentation is different, but you can see the historical warning on archive.org, which looks like this:
So if some SDKv1 addon depended on accessing private internal details of the engine, and these features are no longer accessible with SDKv2 - then I'm afraid I have to say we did specifically warn about that. And it also goes to show it's not enough to have a warning saying not to do something - people ignore it and do it anyway. You have to use encapsulation to enforce these rules in the software itself. That's a big part of the reason encapsulation was invented decades ago.