No, not really.
The difficulty is all about supporting different flows for managing synchronization. These protocols all do the same thing, but they accomplish it differently.
The problem is usually about who is in charge of the clock, and how that is expressed.
In RAAT, the clock master is flexible and changeable mid-stream. It could be the server (in theory, but not in practice today). It could be one of the endpoints.
In AirPlay, the clock master is the server. No exceptions.
In Squeezebox, the clock master is the device with the slowest clock, as determined by the server dynamically. This might not be the same device all the time if clock speed drifts. The primary (annoying) limitation with squeezebox devices is that you can tell them slow down (pause briefly), but not to speed up (skip a brief portion of content), which is why the slowest guy runs the show.
In Meridian, the clock master is elected by the server, and can’t be changed without breaking the stream. Meridian also doesn’t support drift compensation. The entire flow is very rigid. There’s a good chance that Meridian would be left out of any plans to unify zone linking across technologies as a result of all of this.
That’s a lot of different views of the world to reconcile, and I worry that a system that attempted to do it would take a lot of time/effort to build, and ultimately would never become stable enough to trust in every permutation.
At some point, inexpensive RAAT options will make all of this kind of moot. Almost everything has an aux-in. If/when we could find our way into a little inexpensive streamer at a ChromeCast like price point, using that for network streaming might make a better product than attempting heroics to unify a bunch of technologies that weren’t really built for it.