Time zone+daylight savings: I think the handset does not care about these settings, the time itself what matters. I did not implement this part, but I never noticed because the driver worked without any problem with incorrect timezone settings.
Elevation: There is no way to set the elevation via serial protocol. It is most likely reset by the handset when longitude/latitude are set.

If you find these settings crucial for you, you should disable the handset update in KStars.

How can time matter but not time zone or daylight savings.

You mentioned that

Time: 18:45:54 (correct)

The handset will use these numbers and the latitude/longitude, it does not care about if the timezone is incorrectly set, if the local time is correct.

Then why would we always have to enter time zone and daylight savings time into the HC?

There must be something wrong because I found that it didn't seem to know where the meridian was. So I changed the geographic time zone in Kstars to UTC offset 0 (instead of -5 as it should be) and then the mount behaved correctly. It did a meridian flip if I tried to cross the meridian and it was pointing in the correct direction as I directed it on the Kstars map. I used low angle targets just east and just west of the meridian.

There must be a disconnect between Kstars understanding and the mount's understanding of the time parameters.

Thanks for the testing. I am almost completely sure what is the problem. I checked the documentation and the negative GMT offsets need special handling that is why I did not experience this problem here at GMT+2. The driver had these kinda huge bugs in every corner before my refactoring. This time handling is an earlier implementation and it seemed to work hence I did not touch. I will check today after work at home.

That's great! I'm looking forward to the fix.

Just a quick question - will this driver work with guiding (via mount control) or will I need to do guiding via "on-camera"?

@gbeaton: I have a bad news for you. I can't reproduce your problem, everything works as expected, I can sync negative GMT offset to my handset and the time+GMT match between KStars and the handset. I have also a V3 handset, the only difference that I have the latest firmware installed: v3.39.05 or the problem is the macOS environment. When you connect and sync the time, check the following before disconnecting from KStars:
- Is the GMT offset good in the handset inside the manual menu?
- Is the GMT offset good in INDI/Synscan/Site Management tab?

The daylight saving is never set on the handset, it is included in the GMT offset.

Guiding: Yes, synscan does not support guiding, it must go though the camera.

I'm working remotely from a Mac to a StellarMate via Wifi. This setup works fine with the EQMOD driver but not the Synscan driver. (Of course the stellarmate does not have correct time since it has no backed up clock, but thats not supposed to matter since its just running servers.) I'll try direct from the Mac again.

Ok. The problem can be on the Stellarmate. There is a certain code line in the driver which can be a problem on other architectures. I will also retest with my RaspPi setup on my balcony.

You are right. I seems to be working when I control it directly from the Mac. And the time looks good in the site management. However, when operating remotely, the time is not correct - see attached screen shots - the first one is when operating remotely with a stellarmate.

I think you are the first user of this driver on an arm device with negative GMT offset. Anyway, I fixed the problem:

github.com/indilib/indi/pull/543

Actually kecsap, I think I had that problem about a year ago in 2016 when I was trying to use an Orion HDX 110 with my Raspberry Pi and connect to it from my Mac. At the time, we did not figure out what the issue was, instead, I gave up on the INDI Synscan driver for this mount, got the correct cable, and went ahead with INDI EQMod. So we never did resolve the issue at the time.