Construct 2 is great: it has an extremely intuitive syntax which allows you to develop games almost as fast as you can think of them. However, I think there is one place where it can improve: Families.
In design, we try to kill multiple birds with one stone. We do not want to write functionality we have already written. Families tend to take care of this. We can take anything to which we want to give that functionality, and simply drag it into a family. This works for small projects, where you might have one or two players, and a few types of enemies/ terrains etc.
However, on bigger projects, when good object oriented/modular design is extremely important to save time later on, issues arise in Construct 2:
First: Families can only have generation. Let us say that I make a family for talking NPCs. I write very basic, open ended functionality for talking. It covers the structural work of putting up the speech bubble, etc, but it is still up to the children to decide how. And so, I decide to make two more specific families: ordered talkers, that say a set of phrases in order, and random talkers, that say phrases in a random order. I then make several different NPCs that use each family.
Unfortunately, Construct doesn't let me do this. If I wanted to make OrderedTalkers and RandomTalkers, I would have to choose between making two independent families and rewriting the basic talking functionality for both, or rewriting the specific functionality for every single object I make. This could get encumbersome if you wanted to make a game with hundreds of NPCs that talk in slightly different ways.
The solution is simple: Allow sub families: Families whose children MUST be a part of a grand-parent family, and therefore have all the functionality of the grand-parent family.
Second: There is no absolute "Object" Object. Say I wanted to make a game with destructible enemies and environment. I write a family for anything that has HP and can be destroyed. There is a problem though. For walls I use tiled backgrounds. For enemies I use sprites. The destructible family only really needs the "destroy" action and collision condition. Both tiled backgrounds and sprites have those, so why should I have to rewrite the destruction functionality for both types? Shouldn't there be abstract "Collider" and "Destroyable" interfaces which sprites and tiled backgrounds implement?
Solution: Make more general single purpose object types which types like "Sprite", "Tiled Background", "Array", and "Nine Patch" extend so that programmers can cast different objects into one type when handling common functionality.
Third: If all else fails, perhaps just allow us to manually cast objects in events, and it is our responsibility to make sure objects don't get miscast.
Will this affect every game developed? No, but Construct does say that it is meant to be a viable tool for professional developers, and I think that adding something like this would be a large step towards that goal. I also don't think it would complicate things for casual developers, and it could be achieved in the code free approach.