Your assuming is as good as mine.

I assume that poeple who ask how lerp works, ask how lerp works.

Lerp, when used with a liniair lerpfactor, wil indeed move at a liniar speed. So yes, you are right.

But, lerpfactor can as well be sqrt(abs(counter – 1)) ... where 'counter' goes from 0 to 1

Lets split things up. Lerp can (indeed) in two ways.

Method 1.. lerp(StaticStart,StaticEnd,DynamicFactor)

Method 2.. lerp(DynamicStart,DynamicEnd,StaticFactor)

Method 1 is (in my opion) the base-lerp, the base to learn.

Awesome to do grid movements, by instance. Base means also that it has no 'side effects'. It works as intented. And it is very easy to use.

Method 2 is (in my opion) a version that brings problems that have to be countered. **Yet, you will have to use it when Start or/and End has a dynamical character.** Not because of the smooting. In my opion that is mis-use. And yes it smooths, but more by accident, than intended. But you will have to take care of the problems.

Dynamical character ? When lerping a moving sprite to a moving sprite.

(In the above given situation Start and End are not dynamical)

What problems you will meet ? (you suggest to use this method, but dont tell about the problems)

Well,

The lerp will never ever arrive to its endpoint. Causing all sort of problems, that fill the forums. When lerping a camera, the camera will start shaking when the lerp is close to its end.

When close to the End, the value returned by the lerp will change in very very small amounts. Since positions and angles are always 'calculated values', this will result in randominess on sub pixel level. You see shaky sprites.

Most people use 'lerp' in a 'every tick' event. But since this lerp never arrives, and since the calculations get slighty heavyer, this lerp will just run every tick and it will eat noticable CPU.

That are my 10 cents, dont know the exchange rate.