Please forgive me if I've misunderstood, but let me make an attempt to explain this.
In accordance with the example provided, it appears as though you want Construct to decide which actions are appropriate in a given situation. You have a setup where two values are used to determine which action is to be taken, provided one or the other is true at the time. If VALUE_1 is true, you want to make the Sprite move 10 pixels left or right when the appropriate arrow is pressed. If VALUE_2 is true, you want those controls reversed (left arrow moves right, and vice-versa).
The problem you're claiming to be Construct's design flaw is in reality much simpler. As soon as you set both values true, which you indeed do at application start, you've created your own paradox. Now, one press of the arrow moves your sprite 10 pixels in that direction, and 10 pixels in the opposite direction, with a net gain of zero. The Sprite does not appear to move because this all happens in one frame.
This is not so much a factor of learning curve so much as it is just realizing for the first time you have to be mindful of how you set up your events. In this case, if you're using two separate variables to determine which method of control to use, you have to make sure that the two cannot both be true. You need to have a system of telling
Construct which event should be true at what time. Construct itself, nor any other programming platform, can ever determine how to handle this situation without further input from you or the user.
To address your first issue... "Sprite" is no more than a default name for that object. It is suggested at the creation of every object that you name it yourself. This can be done by clicking on the new object and going to the Common Properties panel (by default on the left of your screen), and changing the object's name at the top. This change is in fact
reflected in the Event Editor, even retroactively (meaning you do not have to also rewrite events when you change an object name).
[color=#4040FF:2lame8jn][ASHLEY: Perhaps a "Please name this object" dialog box at the creation of certain objects is a good idea?][/color:2lame8jn]
About starting events with what you call "flow events." In short time you will realize how limiting that will be. Please consider playing with one of the tutorials available on the site to get a feel of how eventing works. In general, it works like this:
AND IF (this),
Then do something.[/code:2lame8jn]
The reason you cannot limit starting events with "flow events" is something you've already pointed out. It does
limit what can be done with the program. Allow me to explain.
We have the same road you wish to drive on. We have cars on the road and some stop lights. We must tell the drivers of those cars what to do when they encounter a stop light. The easy thing to do would be:
[code:2lame8jn]IF Car is near Stop Light,
AND IF Stop Light is "Red,"
Then stop Car.[/code:2lame8jn]
However, we only have system events to help us here. Unfortunately for us, this method of picking objects does not classify in your definition as a flow event. The System Object, one of the flow objects you describe, can give us true or false comparisons between two variables to potentially work around this. However that method is clunky, and our situation is better resolved by using "pick object events."
Does this mean you have to be careful about making a conflict to this Stop Light event? Yes. That's just part of the puzzle you have to overcome.
Regarding loops, I do not believe you're ready for them yet. You correctly point out that they can be mirrored by standard events, but that is not the point. Loops are designed to run in between ticks to perform actions that must be computed in advance. I or any of the other people here can help you with those when you need to use one for the first time.
I hope this has helped you understand the process a little better. Just keep practicing with the event sheets, and be mindful that Construct cannot read your mind to know what it needs to do and when. You just have to take that extra step or two to let it know what you are thinking.