I am not sure I can agree concerning the second loop in the code example. The fact that the loop counter was not one according to the definition and therefore the rule was not violated is in my opinion the wrong way to look at it.
Rather the opposite: x is clearly used (and recognised by the reader) like
a standard loop counter: it is initialised in the first and used for the condition in the second field, only the programmer wanted some trickier modifiation and put it somewhere else. So what makes the code non-compliant is not that x was not a loop counter, but that its modificator is not placed in expression as it should be.
It can be assumed that the programmer probably wanted to have *2 the only
modifications of x, so "correcting" the code examples by adding an extra ++x would blur the focus of the problem. The question is: should the second loop be valid in the sense of error avoidance?
Concerning the first loop, it can be argued whether this should be a valid for-loop or not according to 6.5.3: adding an extra ++x would render modify() as a second modificator of x, but even then x would strictly spoken not
be a loop counter by definition since condition does not use a relational
operator (item b). According to this argumentation, this would still be not
a violation of 6.5.3:
This brings me back to the consideration that x might still be seen as the loop counter, but I would not insist, since if not, rule 6-5-1 would kick in.