Hi all,
just wanted to report that the long lasting bug of AF Overscan function not working properly with the Sesto Senso 2 focuser has been found and addressed.

1. Bug explanation
With Sesto Senso 2 focuser the use of the AF Overscan functionality was not working as intended.
The intended use of AF Overscan is to clear any possible backlash by engaging the movement of the focuser only from one direction, in this case by issuing a "Focus In" as last movement with every instance.
As an example, with these settings:

• initial position: 1000
• step size: 100
• AF Overscan: 50

The focuser, while doing a "Focus Out" movement:

• start from position 1000
• move out the focuser by 150 (step + overscan)
• move in by 50 (overscan)
• end at position 1100 (start position + step)

But with the Sesto Senso 2 focuser you get:

• start from position 1000
• move out the focuser by 150 (step + overscan)
• move in by 200 (overscan) <- in reality, this does 1000 - 50 (old position - overscan), and where the fix is targeted
• end at position 950 (start position - overscan)

The same problem can be replicated without AF Overscan just by issuing 2 movements in rapid succession (no matter the direction).

2. Root cause
The root cause was at the driver level, where the INDI driver would report a change in status (busy/ok) before changing the position:

• Moving: {"pos": "1000", "busy": 1}
• Moving: {"pos": "1000", "busy": 0}
• Moving: {"pos": "1100", "busy": 0}

And kstars would issue the new movement using the old position.
The correct order would be:

• Moving: {"pos": "1000", "busy": 1}
• Moving: {"pos": "1100", "busy": 1}
• Moving: {"pos": "1100", "busy": 0}

3. Solution
On the KStars side, a new parameter has been added: AF Overscan Delay; this parameter can add a delay between Overscan movements, preventing the problem of the driver bad reporting.
On the INDI side, a couple of fix were made, targeting the status report and the order in which it appera inside the updatePosition function of the driver.

4. Why should I care?
Primaluce Lab reports that the Sesto Senso 2 has no backlash, so why should I care?
Well, there is hardly any mechanical contraption that does not have backlash in one of it's components; it may be the autofocuser, or the focuser itself that introduces a backlash.
Having a way to ensure that the backlash impact is reduced it's always good.
In my case I have a rack and pinion focuser, no matter how good it is, a minimal backlash is expected. Clearing this backlash is always useful in precision equipment.
Also, the addition of the delay in the Overscan procedure is a good addition, since it let stabilize the movement of the focuser before moving it again; this is expecially useful with heavy payloads.

5. Relevant links:
Original discussion:
- [Kstars 3.6.9][INDI][Sesto Senso 2] AF Overscan not working correctly
Github bugs:
- Sesto Senso 2 Bug on TimerHit breaking AF Overscan in Ekos Focus
- Sesto Senso 2 Not reporting focuser position correctly
Github PR:
- Sesto Senso 2 changing state before changing position

6. Thanks
Thanks to @john for the changes in KStars and finding the root cause.
Thanks to @Jasem Mutlaq for the changes in INDI and the fast response to the issues and PR opened over at github.
Thanks to myself (?!) for being a good button pressing log machine!

Cheers,
Edoardo