As they have stated above, the result of c_move is frame rate independant.

But the difference in results you are getting is because it will always return the exact distance covered in the last frame. And remember, if you are using the code from your last request thread (framerate independant movement), the value you are passing to the c_move instruction was speed multiplied by time_step in your code, therefore to get framerate-INdependant movement you are passing framerate-DEpendant distances to c_move. And that causes the framerate-INdependant results you are getting from c_move each frame to now be different depending on different framerates.

Explanation:
Also another important thing to keep in mind, I feel you are confusing the concepts of distance and speed.
Remember:
speed=distance/time
time=distance/speed
distance=speed*time
You obviously know these formulas already because you got them right in your code from your previous thread, but I have the feeling that when using time_step they get a little more confusing since it is easy to forget that for a computer time is directly related to both framerate and time_step. As a generalization, consider fps=time in these formulas, since you could generalize that time_step is calculated from the time the last frame took to complete.

-In the other thread you had to multiply your speed with time_step to get the distance covered per frame because dist=speed*time
-The result of c_move is the exact distance covered over a period of time (in this case, the distance covered last frame).
-By dividing the result of of c_move (distance) by time_step (time), what you are actually getting is speed (not distance). speed=dist/time
-By changing the framerate in the example you stated above, you are changing the time (of each frame), and even though c_move result is just distance, since distance=speed*time the program is modifying the speed (or what is the same, the distance per frame).

Conclusion:
- c_move always returns framerate independant distance of the instruction. If you pass it a constant distance you get constant results ignoring the time (but that will obviously produce different speeds at different framerates).
- Remember (in your previous thread) you are not passing a distance to c_move directly anymore, you are now passing a speed*time. That is also a distance, but not an absolute distance ignoring time anymore.
- If instead of giving c_move a distance, you give it a speed and a time, your result is a distance modified by speed and time.
-In your above post you said that you got the correct (constant) distance values by dividing it by time_step, that is incorrect, you are now getting a constant value, but you are confusing distance and speed, what you are really getting now is speed because speed=dist/time. You gave c_move speed and time, and it correctly returned distance. Afterwards you took that result (distance) and divided it by time, transforming it into speed again.


In sloppy game programming people ignore time_step, so their game is designed only for their computer because it is framerate dependant. The above formulas still apply even when programmers dont use time_step, but the programmer is choosing to ignore time, making speed and distance different on other computers since they choose to ignore time.
All three things are always depending on eachother, a change in one (for example time) whether you program them in or not, will always effect the others.
By correctly accounting for time in your program now, it will modify speed and distance to get correct (constant) results on all computers no matter the time (framerate). When not programming time, those computers still modify distance and speed depending on time, the only difference is that time is now out of the programmer's control and left for the computer's framerate to modify speed and distance with no control.

You are now correctly taking all three variables into account when programming your input to the computer, but still thinking only with two when analyzing the data it otuputs to you.

EDIT:
Wow, that was much longer than I thought! Again, sorry for the long read, but I hope it helps you out.