This throws up some interesting issues.
The behaviour is not ASCOM compliant. The fundamental principle of ASCOM driver development says:
Do it correctly or signal an error.
This is the basic “contract” between a driver and its client application. Your driver absolutely must either do what it is asked or signal an error condition for the client to trap. Unless the client gets an error, it will always assume you have done what it requested and continue in its logic under that assumption. This means that you must not return “illegal” values for properties in lieu of signaling an error, or “try” to do something and return whether it was done or not. You cannot expect client applications to know about limitations and quirks of your device and avoid them (see the first principle above).
Silently ignoring a command is not an option.
However the screen shot shows some interesting things.
The Ra of the mount and the Ra reported by the solver are different by nearly 8 hours - getting on for 120 degrees. With differences like that it’s almost impossible to say what position the mount should be set to by the sync. Not only does the Ra and Dec have to be correct but for a GEM the pointing state must match how the mount is set. There are a number of cases where the correct mount setting can’t be determined - when the sync position is close to the meridian for example.
Using Ra and Dec offsets to sync could lead to all sorts of problems because the mount axis position and the Ra or Dec are so different. The mount could think it’s crossing the meridian 120 degrees before or after it actually is.
Sync is intended to allow a user to make minor corrections to an aligned mount position, not as a way to align a completely unaligned mount.
As Horia says getting an approximate alignment is pretty easy.