It's been a while since I was working with the dome class code, and I expect to be back to it in the very near future, I've been buried in client projects with no time to look at indi lately.
The indi dome class already provides dome synchronization in a manner similar to how the ascom POTH gadget works, ie once configuration is in place, dome slit will automatically track where the telescope is pointed, with all the math to deal with offsets handled transparently under the covers. The setup is contained within the dome specific driver which looks after translating azimuth co-ordinates into hardware specific co-ordinates, be they degrees, tick counts, or what have you. The relationship between 'real world' and hardware co-ordinates is typically handled by the home sensor, and is a one time setup in the dome configuration.
As I mentioned, I haven't been working in this area for a while, but what I do remember, the indi base dome class currently doesn't provide properties for altitude, it treats the slit as an 'open / closed' item. I plan to change that in the not to distant future as the domes we are installing here have the ability to run with partially open shutters and we plan to use that capability.
I haven't started committing code for the NexDome yet, it'll be coming in the near future after we have had a chance to test it all on live operating domes, which aren't fully built yet, but should be over the next couple of weeks, waiting on a contractor to finish a foundation right now, and that project has been delayed by seriously bad weather over the last 10 days.
As for why snooping between telescope and dome, that's done for the exact same reason the ascom folks wrote all the math into POTH. Once the dome is set up and configured for the local installation, any client that can point a telescope will inherit correct dome pointing, without ever having to know about the dome. The dome is slaved to the telescope and the slit will remain in front of the telescope objective as long as it's slaved. This allows for programs that have no knowledge of how to point a dome to still run the telescope and it all 'just works'. FYI, just doing a translation from RA/DEC directly to azimuth will NOT correctly orient a slit dome if the telescope is on a GEM mount. The pointing math under the covers needs to account for all of the mount offsets, which are again, site specific variables. the only one that works correctly in the simple case is a fork mounted system where the attach point to the forks is precisely at the center of the dome sphere, all other configurations require more complex math to correctly orient the slit. I know of no planetarium style programs that incorporate that math for dome slit orientation, hence the need to bury it into the lower layers.