In the Windows case it is pretty clear that it converts the JSON into something ASCOM-compliant and sends the request to the device. I write a client program, look up the JSON semantics for this device, and send the necessary JSON to an ALPACA server.
Let's say I want to control a filterwheel. I'm potentially interested in ALPACA but still trying to understand what components are needed to make this work on a completely Windows-free setup. There was a project called wINDI that was reported to be an ASCOM->INDI bridge, but I don't know the status of it now. Since I don't see it happening, and since it makes sense to have a Pi on a telescope running an INDI server with perhaps a primary ASCOM server connecting to the human-interfacing programs, there has to be a catch I'm not seeing.
None of which are particularly difficult problems to solve with a bit of code Even if things are completely mismatched, a simple socket program with a conversion between driver specifications could make it happen.
The only reasons it may not be are that 1) Nobody thought of it yet, or 2) The XML specifications for the drivers have become too differentiated, or 3) The port for the two server types is different. TCP/IP XML is common between both platforms. A primary INDI server should be able to talk to secondary ASCOM or INDI servers and likewise a primary ASCOM server should be able to talk to secondary INDI or ASCOM servers. But it seems to me that if they don't do that yet, they should. I don't know the answer, because I don't do Windows. Both ASCOM and INDI have provisions for distributed remote servers with one primary server. They are both TCP/IP XML message platforms. The real question should be, "Can an ASCOM server talk to an INDI server.
I also find the INDIGO framework to work quite well. As has been said above, if you need something now (and you don't want to write your own drivers etc.) then its better to stick with the other suggestions. It's a bit of a chicken and egg situation and time will tell if it finds any traction. The problem at the moment of course is that there are very few (if any) Alpaca drivers and clients available at the moment. I don't think it is released yet but it shows what can be done. developed a Linux client and RPi drivers via the Alpaca API. you could have an Alpaca client running on Linux connect to an Alpaca driver running on the Raspberry Pi. Not sure what the rules are on posting links to other forums but if you look on cloudy nights and search for a recent thread called 'Raspberry Pi and Alpaca' there is a guy who has just done that i.e. I think the arrows in the diagram are a bit misleading, you can remove the entire left hand side of the diagram and it will still work i.e.
So it really only comes into play if you want to include some component running under the 'old style' ASCOM framework.
You only need the 'remote server'/'ASCOM remote' part if you want to use an existing Windows client (running on normal ASCOM) to connect to an Alpaca device driver (over the Alpaca API) or if you want an Alpaca client to connect to a regular ASCOM driver on a Windows machine. However, as far as I see the server module for Alpaca needs Windows + ASCOM framework to work. Yes, it was said that ASCOM Alpaca wouldn't be OS dependent.