As far as I know, cocos2d-x does not use independent threads, rather the Update methods are called hierarchically - so first the scene calls its child update methods and each child calls its child update methods. So
Your layer update precedes your child update.
So whether getLocation() gives you the current or previous location depends on whether the action is triggered before or after the sprite’s update method.
I’m not sure, but I would think that the action updates the sprite first.
exactly… it worked 
Only thing is I need to tweak the angle inside MySprite.cpp because it depends upon the intial direction where the arrow is heading…
So… I think now I realize that this is exactly what you and even @hzlov was trying to say the same…
And this is exactly the same thing I was not willing to try this similar solution before posting my first post because of confusion that whether getPosition() of the sprite will get me the currentPosition or nextPosition…
And yeah… main idea is that I really needed previous position and current position but the current position will help me only before my sprite is getting rendered otherwise of now use…
I tried it on a random catmull path and it worked there also
And @Maxxx , what do you think… Do I seriously need to make a separate class for the sprite?
Can I use the update method of my layer to set the rotation for sprite?
I think we can… I’ll try that too
Do you NEED to? Probably not. But, if I were you, I would.
In fact it is my normal policy to make my own child classes of just about everything!
Why?
Flexibility!
If you create your own Sprite class - let’s call it CUSprite - with the ‘face direction’ functionality - and maybe add a bool, ‘faceDirectionOfMovement’ which, when true runs that functionality, when false just acts like a normal sprite.
Now all of your sprites can be CUSprites. You can set the faceDirectionOfMovement to true or false - and you never have to think about it.
If you put the code in a layer and want to perform that functionality on more then one sprite, you will end up repeating code every time.
Now, maybe you want another sprite to have some different functionality - say you want it to play a sound whenever it collides with something.
You can add that functionality into your CUSprite class.
Now, if one of your sprites wants to play a sound when it bounces, set a few properties and you have it.
Now, say cocos2d-x v5.0 adds ‘play a sound on collision’ functionality; it will almost certainly be implemented in a different way to how you have done it. So, you change your code tin CUSprite to call the new cocos code - and that’s it - you don’t have to hunt around for everywhere you detected a collision and played a sound!
Yeah… great approach 
This is a great post, the only thing I didn’t understand is how to avoid jerkyness when the Sprite rotates on its path? Can anyone advise further ?
I rem. this post 
You revived it after 2 years 
Can you show your code? It shouldn’t add jerkiness.
It was my mistake… sorry. I had a delay in the sequence!