During the last half of the spring term my class at university was given the task to create a game using Construct. We were given 9 weeks and between 1-3 programmers per project.
The general experience is that Construct is entirely too filled with bugs to ever be useful in its current state. We spent more time finding work-arounds and tracking down bugs than we did actually getting any work done on our games. The bugs were so numerous that it was good we were working as a class... so most bugs only had to be tracked down once. After one group figured out a bug, the other groups could save time. Python is not as well integrated as it should be, subevents are ok... as long as you don't want to specify anything with OR or ELSE... then it has a tendency to not work.
Many features seem to have been just tossed in without much testing. Or features are half-added and half-completed. I'm well-aware that this is open source and such, but Construct is still not at the point where it is useable as anything except the roughest of game prototypes. Or as an exercise in patience and using unstable software. It does inspire creativity and problem solving though.
We were also unable to merge our files. This made groupwork very interesting. Most games today are mostly made in groups or teams. Not by individuals in their basements. As we are studying computer game programming, it is vitally important that we learn to work in groups. This meant that people had to work in separate cap files, then REDO everything in the main cap file once things were working correctly, and hope that nothing would cause bugs or conflicts. The other option was to have only one main cap file and have the other people in the group frantically looking after bugs and once a bug is found, try to figure out how to fix it without breaking anything else. The end result, at least for my group, was basically having a full-time bug finder-fixer.
Construct (Or "Scirra Destruct... click and crash" as we were calling it by the end of the project) was chosen over other possible programs for this course because it was open source. From comments the teachers have mentioned, open source is not terribly useful when the libraries required to compile and hence fix some of the many many bugs, are not open source. As with most free software, filled with bugs was expected... but not being able to fix them was just silly.
The REALLY ugly ribbon display was also very annoying. If working on a laptop or computer with a small screen, you quickly find that you have no space left to actually build your game. The menu bars which were almost required to be up all the time due to the information, also took up a ton of space on the screen. The layout works well... IF you have a large monitor. Otherwise, rather silly!
Construct was not all bad, as mentioned previously, it is a good learning tool. It also has possibilities if it is not abandoned and if many of the bugs are fixed. It might be an idea to stop attempting to add new features and get the current features stabilized first. I'm aware we were using the 'unstable release' but it is not possible to use the stable release when all help, advice, and such only refers to the most recent unstable. And the first response to any question is 'be sure you are using the latest unstable!'
Most groups in the class did manage to get games together. I don't think any of the groups have managed to create 100% stable games though. News releases and other information can be found at:
https://projects.gscept.com/projects/mp2010
Each group also has a public folder on their repository... swapping out the # with a number from 1 to 7 will get you there:
http://gscept.com/projects/games/2010/G#/public/