in c++ expressing intent is a bit over-enthusiastic. intent you could already express in c, the problem is the compilers are too stupid to understand it. if you want to express something in c++, it better be the desired assembler-code generated underneath. again, same can be done in c. difference is only that in c++ you additionally are capable of expressing the compiler's behaviour when encountering some rare or hopefully rare cases of misunderstanding between programmers. unfortunately, I am not aware of any programming language capable of expressing intent, there's always quite a lot of bureaucrazyness to overcome first. in a simple case, you may express your intent that whatever turtle walks a few steps forward and turns left and so on, always leaving a trace behind. but after that walk there will appear some beautiful star on the screen which you couldn't have generated by simply saying "draw me a star". this is a problem inherent in what we call "intent", we'd like the computer to make decisions for us, and if we're unhappy we'd like to tell it to try again and specify our intent a bit more clearly. this actually is a searching problem, solveable by loads of supercomputers attempting to decode everything surveillance has gathered about human beings. when you say draw me a star, there are many ways to do that, the computer would need to know them all, either by collecting that info or better yet by comprehending what it is that makes a shape into a star-shape and then searching for all such shapes. once that's done, a random shape could be chosen. stating intent basically has little to do with programming, intent is what google is after while programmers tend to just collect a list of possibilities on their own and choose among such a limited list.
I know it's a bit off-topic now, but let's use it as an example: the "Moveable" concept is a bit fragile. suppose you have a lib for numbers, are numbers moveable? principially a number could be moved, it does not depend on memory-position. however, if there is a central cache, containing all numbers so they are stored only once and never again, would such a cache then also store all positions where such numbers are referenced from? silly idea, but it destroys the moveable property. generally if you depend on 3rd party libs, the underlying objects could easily change in a way that breaks moveability, without changing the interface.
another example: usually c-programs either pass by reference and thereby introduce non-reentrant code (to store the created object in a static variable), or they create copies of lots of objects, cluttering memory so that garbage collection is needed. c++ recently introduced R-value to solve that. so, you have some sort of pick-casting to prepare a value for that kind of function, then you must write a pick-function to move over another objects data-ownership to yours, and call a setPicked function for the other object so that future access to its data generates runtime-errors. if you do such a change with existing objects, then you'd better remove copy-constructor and rename it into a 2-argument constructor. additionally the single equal-sign operator must perform the picking and therefore isn't allowed to pass a reference to this object on output, it returns void. then compile your sources and whenever copy-constructor or assignment is used, you must then make a decision based on context: should a picking or a deep-copy be performed? the original author did not express his/her intent on that topic, you must add more details to how the intent really looks like. and now suppose you have a co-worker who is unable to comprehend the notion of picking and deep copy. now you must change sources again, this time removing expression of intent again. well, in that case c++ offers some possibilities to just change definitions, so it compiles with intent inside even though it wont get used. but if the coworker doesn't continue that statement of intent, then your code has mixed depth of exactness, it is inconsistent, your stating of intent becomes useless. so you need tools to mark all changes done by that co-worker for reviewing and add this increased intent yourself.
what I claim here is, with parallelization you'll face all the same problems again! what we really need is more code-refactoring tools. the whole argumentation with programmers are lazy, small code is beautiful, easiness over changeability, all that is really a moot point in face of what nowadays IDE can do for you. the for-loop in old-style you presented, nobody wrote such for-loops actually, they just told the IDE to create such a loop for them! imho the old iterator loops are to be preferred over the new foreach loops, there you did get the actual iterator into hand and not the value it is pointing to. you can do a lot of stuff if only you have the iterator!
my suggestion is, dig out some good IDE, and improve it for easier parallell programming. I'd choose to use qt-creator, although my favourite is U++. but if you wish, you can as well use clion. or preferably, write code for code-refactoring, portable among all 3 IDEs, code that works on linux-kde c++ as well as on windows java...
I must emphasize: using templates or whatever pre-compiler programming, this will increase build-time and steal memory-ressources during compilation. if it isn't necessary because a good IDE can do all that much cheaper, why not use that option? why not code-generating instead of compile-time execution?