Some things that I can think of:
- Multi-platform would be good, even if it's only the products of the application.
- I do not know much about this part, or if the current one works this way already: A framework where the scripting support is as tight and transparent as possible. If possible, when creating plugins, the developer does not usually need to manually provide scripting access to the functionality provided by the plugin. It's generated automatically, ideally. Perhaps access to behaviors and such from python could be like player.Platform.XSpeed = 200.
- tulamide has a good point about data types. Construct could use more support for those, in general, but user-defined would be very handy. Something similar to simple classes or structs could be very handy, even if just for the namespace organization. Arrays could use some more methods, like a simple sort, find, and a push and pop able to make easy stacks or queues.
- The ability to store direct references to instances of objects, and manipulate multiple instances of the same object more easily. For example, let's say that you have one object that needs to keep track of two (or more) of an ever-changing bunch of instances of another object. You need to compare or manipulate both (or all) of those instances in some events.
The only way that I know of to do this is to store their UIDs in variables, and put the object in question into two (or more) families so that you can pick and reference more than one instance of that object in an event.
Perhaps variables could store references to instances, or a system function Object(uid) could be used as an indirect reference, or the objects could simply be indexed in a useful way, like "Sprite[index]....." I'm thinking that the index would need to be UID again, though, since objects are often spawned/destroyed a lot, making indexing problematic.
- Conditional branching and functions need to be more powerful, IMO. ELSE and OR need to work well under all circumstances. I suppose that 'OR' could be replaced with an 'If any of the following are true:' condition if it seems easier to use.
I like the current function object pretty well, though I dislike the whole 'add parameter' thing. I always call them as expressions. They could use some support for local variables. Not sure how I'd implement that, though.
- Speaking of local variables, more variable scopes could be useful. Groups are a unique and interesting concept in Construct. They can be used as a sort of conditional branching solution with the ability to enable and disable them. I think that they could also use local variables. Perhaps there are some other improvements to groups that could be made to make them even more useful.
A common want that I've seen is the ability to be able to reset a layout to it's initial state, completely. This can be problematic with global variables being used quite often and such. Perhaps having local layout variables could help with this, so that a layout can be 'reloaded' to an initial state more easily.