What is difference between the design principle of separation of mechanism and policy and the principle of separation of interface and implementation?
They have nothing to do with each other, so it is difficult to describe what the difference is between them.
Separation of interface and implementation is "I don't need to know how the car works in order to drive it". If you know how to drive a gas-powered front-wheel-drive hatchback, and you are asked to drive an electric rear-wheel-drive coupe, the performance characteristics might be different than you are used to, but fundamentally you use essentially the same steering wheel and pedals and light switches and whatnot to operate both vehicles, even though their implementation details are completely different. You only notice the difference when you have interactions with the vehicle that have implementation dependencies, like refueling.
Separation of mechanism from policy is that the car is built to go up to 100 miles per hour in any direction it is pointed, and the driver is responsible for going the correct way down the highway in the correct lane at the correct speed, not the car. The policies about what the speed limit is and when you are allowed to turn left are not embedded in the engine except insofar as the engines were designed by people who knew what likely policies would be enacted.
Now you might then wonder what happens when cars become self-driving, and the answer is: we continue to maintain the separation between policy and mechanism in the design of the software. The choices about when to brake and when to accelerate are made by encoding them in policy code that has executive control over the subsystems which steer the car, actuate the brakes, and so on. Those mechanism subsystems do not know or care about policy; they just do what they are told.
I am a strong believer in keeping mechanism code distinct from policy code. Here's another way to think about it: policy code describes what the code does in the level of the business domain. "Produce a sorted list of the last names of all our customers in London" is in the business domain. "Swap these two out-of-order elements in this array" is in the mechanism domain. The mechanism domain implements the policy, but it does not encode the policy. It encodes facts about array elements, not about customer mailing lists. When code mixes the mechanism and policy domains, it gets harder to reason about and maintain.