Very cool! I like that the author chose socket-based communication over a C FFI, which I assume might lead to better reliability and a cleaner API on the Lisp side. Are there any disadvantages to sockets vs. FFI? Any additional, perceivable latency?
I chose to use FFI for sockets so that I can have access to sendmsg(), which lets me send file descriptors on the same message as mundane I/O. It also comes with a small bonus that I get to use scatter/gather arrays to move I/O around, which means less byte-shifting when having to deal with incomplete messages.
I'm not sure I understand your question between sockets vs. FFI. Anything not built on FFI would have to come from an impl extension (or a compatibility layer, which would still have to be built on-top of the former two). AFAIK not even SBCL's sb-posix send fd's across -- they still list sendmsg() in a TODO.
As for latency, I haven't benchmarked performance yet. I want to write a collection of desktop apps driving Wayflan to make sure the API is solid, before I do any benchmarking. However, I know one possible advantage over C's libwayland. Libwayland stores a message signature as a string, which runs through an "interpreter" to learn how to decode a message. Wayflan expands a message signature into a function directly via a couple layers of macros.
Wayland clients already communicate with the compositor via sockets. This is no different, the main thing will be being able to produce a Lisp-centric API rather than directly using the existing libwayland-client or another library's API.