Seems at this point it would be easy to put it in an ASCOM driver that wraps an ASCOM driver and handles the sync offset in the outer wrapper. Similar to POTH.
The main issue we have is that we should be able to rely on the ASCOM contract. If other manufacturers are not wanting to adhere to that contract then it makes it a mine field to support their drivers. Minimally they should be returning false for "CanSync" and we should respect that (which we do).
So if the driver reports false for CanSync then we won't actually sync the mount at ANY time, even during the centering process. And yes, centering will still work, although without sync it may never converge since the mount's idea about it's location is plumb wrong.
Unfortunately it sounds like the driver is saying "true" for CanSync but then throwing an exception when we attempt to sync it. Which is bad. If the driver doesn't support sync it should just tell us and we won't sync. Simple as that. This behavior has been in SGP for a while now.
To me it sounds like the driver needs to be fixed...but maybe I'm missing something?
This is totally fine provided that the driver reports false for CanSync. They can limit it all they want and even limit it in specific situations if they so desire (close to the pole, etc). But if the driver reports that it can be synced...then we should have the expectation that we can sync it.
Jared