Apples vs. oranges, though. If I read the blog post right, he's demonstrating that he can restart the main Arcan process while an auxiliary process called "waybridge" lives on, which for the Wayland clients is the actual compositor. This still requires the same type of "reconnect and restore" dance, but internal to Arcan-proprietary bits, pushing the problem up one level from the native Wayland exchange.
The blog post being discussed here is about handling a crash in "waybridge" instead, so to speak, and having this ability in Wayland itself instead of requiring an additional abstraction and protocol.
Arcan can use multiple waybridge instances, e.g. one per client, to get some isolation between the clients (from the post), but it does start to sound a bit heavy perhaps (I don't know much about the inter-Arcan IPC though).
That's an irrelevant distinction. In both cases, if there is a crash in the bridging logic, it'll fail. In the QT case, the bridging logic is just living in each app process.
The blog post being discussed here is about handling a crash in "waybridge" instead, so to speak, and having this ability in Wayland itself instead of requiring an additional abstraction and protocol.
Arcan can use multiple waybridge instances, e.g. one per client, to get some isolation between the clients (from the post), but it does start to sound a bit heavy perhaps (I don't know much about the inter-Arcan IPC though).
Cool stuff, though.