So I've been a fan of C2 for a long time, and am a paying customer. I was really excited to hear the news about the next generation of Construct, and like a lot of us here, have a few thoughts. I have NO idea if anyone at Scirra will actually read this, but here goes:
Drop the idea of naming it "Construct 3"
I think including the main version number in the product title is a big mistake! PLEASE don't call it "Construct 3". Look at what Apple did with the iPad. Remember the iPad 2? The iPad 3? Eventually they got smart and just started calling it "The iPad". People have registered domain names, youtube channels, twitch streams, online video training courses all with the term "Construct 2" in them. Now they're going to have to rebrand for Construct 3. And then 4 and then 5??? If you just call it "Construct" (and rename Construct 2 to something that sounds legacy like you did with Construct Classic when C2 was released), you'll be fine and will future proof yourself. People will naturally, casually call it "Construct 3", just as people call Unity "Unity 4" and "Unity 5".
Consider de-coupling the exporters from the main engine
I see a lot of complaints from people expressing that native/desktop exports are constantly being broken or crippled by new NodeWebkit releases. Desktop is still a VERY viable means of delivery, developers can benefit from releasing on Steam, Desura, or by direct sales. The editor shouldn't SOLELY export HTML5. HTML5 should definitely remain one of the export options, but being able to export to a truly native OpenGL app with a minimal native wrapper that just handles windowing, input and filesystem access (-ahem-...SDL...), you could easily target Windows, OSX and Linux natively. The HTML5 exporter could take the same assets and game logic and export HTML/WebGL-centric Javascript. And native mobile exporters could export games on Android and iOS. This is the way EVERY other game engine does it...it will mean more work up-front but having solid native exporters on major platforms WILL sell copies of your product.
Give us Boolean globals
Its unfortunate that global variables can only be numbers or strings. I HATE creating global numbers and using 0 and 1 for things that should just be true/false. What happens if I accidentally set that value to a 2 or 3? Since its a number that's possible, but may break the logic of my game. Maybe I'm just anal, but having global boolean variables would really brighten my day
.NET or not .NET?
I've heard that the current editor is written in .NET, and is why C2 is only available on Windows. Microsoft has recently open-sourced the .NET runtime and CLR (it's even now available on GitHub), I'd expect to see production-ready .NET desktop apps on OSX and Linux within the next few months. I know you guys have even collaborated with Microsoft a bit, perhaps you could get some assistance porting the editor to other platforms? Or maybe switching to Mono and using something cross-platform like Qt or Gtk+ for your UI toolkit...something I'm surprised you guys haven't already attempted!
Plugins Should Be Packages
You REALLY should make plugins owned by the PROJECT, not the EDITOR. Something like how NPM or NuGet works (or hell, set-up a custom repository and USE NuGet if you stay on .NET). Plugins should have a central, searchable, browseable repository for discovering and installing them, and updating the Editor should NEVER wipe them. I don't use plugins right now for that very reason and I feel like I'm missing out because of it. And for the love of God: give us a better SDK for creating plugins! The documentation is pretty much non-existent, and wading through that mess to create a simple plugin is an exercise in futility. Take a note from Unity and give us solid Plugin documentation, and give us hooks to be able to create custom UIs for our plugins.
And if you dismiss everything else I've said here, please listen to this bit of advice:
Give us more advanced script editing capabilities
You yourselves advertise on your website "No programming required!" but that's ABSOLUTELY not true: creating a game in C2 most definitely requires programming. You're just not TYPING your programs into the editor. For those of us who WANT to be able to "program" and come from other languages/engines, having the ability to type-in our events & actions would be flippin' sweet. It can be something as simple as enabling an "Advanced" setting in the preferences that switches the event sheet to just a text document where we can create functions for our events and type-in the actions ourseleves. You guys are 80% of the way there with the expression editor and code completion already in C2, just evolve it a bit further to let us also DEFINE those events and actions from within code. It would make it easier to share code snippets (right now you have to take a screenshot of your event sheet and share it...), it would be so much faster from a workflow perspective (the number of clicks required to simply assign a variable or move a sprite is frustrating), and it would open-up Construct to things you guys never thought possible. Honestly, I think that Construct 2 sometimes gets dismissed by some as a serious game development tool because you're "just clicking and dragging". If you could build your events and actions yourself in an actual script file (if you choose), I think you'd attract more attention from the "hardcore" developer set.
C#/.NET scripting would be awesome, TypeScript would be a wise choice if you stick with HTML5 exclusively, or at a minimum: a Lua API for scripting.
That's all, I'll get off my soapbox now. Keep up the good work, I can't wait to see what you guys have in store for the future!