Under fixed timestep if the frames per second are invariant.
length / by speed = depends on the number of steps per second to traverse a distance not time to traverse a distance. Fixed time step is not even invariant unfortunately in the steps it takes to complete a second.
If i am running at 10000 frames per second vs 60 frames per second i will not traverse the distance a to b at the given speed equally under different timesteps because the speed implys their would be the same number of steps in a second. So unless my speed is affected by target elapsed time i will not get the right result.
If the speed is invariant over time but variable per frame which is preferable currently as mgs fixed timing is a bit screwed up.
Then you change the calculation to be dependent on velocity over time not distance per step.
// which means your speed is affected by target elapsed time each frame.
var i = 1f / elapsedTimeThisFrame; // iterations per second (you will find under fixed this is about 58.86);
var d = Vector2.Distance(a,b); // distance
var timeToTraverse = d / myObjects.SpeedPerSecond;
var framesRequired = timeToTraverse * i;
// this is then the speed you should add this frame to your object.
var speedOfMyGameObjectThisFrame = myObjects.SpeedPerSecond * elapsedTimeThisFrame;
The above here is approximated because it is dependent on having a accurate timing device per frame then a accurate number of frames per second which as stated earlier mg does not.
However this is a much closer approximation this way then the first.
Either way is not really perfect though if there is a lag spike you would skip forward in this scenario.
You can also see that if you accelerated in either situation your time to traverse would change.
To summerize the assumption that there is 60 fps in a fixed time step set to 60 fps is (Wrong).
Test it and see for yourself.