The origins of remote ASCOM are some years ago when we had an ill fated project - ASCOM-X. This was trying to do the same thing - provide a framework for allowing ASCOM style operation remotely and over multiple operating systems.
At its core an ASCOM driver is very simple. Some code withat implements a defined set of properties and methods. This maps well into a text based protocol:
> get RightAscension
< get RightAscension 12.345
> slew 5.432, 15.678
< OK
Other protocols could be defined
So, being someone who tends to move into coding too soon, I implemented something like this - and it worked.
But I made one fatal error. I used UDP as the transport method.
It could have been anything - TCP/IP, files, RS232, fax, messengers with cleft sticks, pigeons, the telegraph - anything that can transport text messages.
Unfortunately everyone who commented focussed on the folly of using UDP, with vast explanations of how it couldn't possible work, especially in Windows. This in spite of this all being developed on Windows.
I gave up, and the whole thing went into limbo until a couple of years ago when some people developed what you now see. What I think they learnt was that public development of this sort of thing doesn't work.
It could hook into all sorts of other systems, the idea of hooking into INDI looks good. Users with Windows PCs running one of the mainstream astronomy applications could have a RasbPi on their scope that handled all the scope managment, guiding, image acquisition and so on. Another pi to handle the dome and weather.
Then, when they see how easy INDI and the linux system is, they will become converts.