I'm not really following through your reasoning. How is breaking the usefulness helping the revenue stream?
Assuming you're an engineer, have you thought about what handing over a "window" from one computer to another actually entails? CRIU can do checkpoint/restore at container/process level - but you actually want it to run on both, no? So you need to split off just the I/O, but at the OS-level per window.
Apple has been doing a lot of work in this direction and they have stuff that actually work (like video calls and to some extent windows. These are processes running on different OS-es with a matrix of hundreds of devices.
It's not something you vibe code over the weekend.
the revenue-driven decision was choosing to make the OS more like iOS, locked down with an app store, rather than macos, which allows third-party applications, browsing the filesystem, dropping into a terminal, etc. with built-in first-party support.
instead of making a computer in an AR form-factor, they made an iPad in an AR form-factor.
Sending multiple windows over screensharing actually seems easier than sending the desktop to me - because you only look at one window at once, the rest don't have to update at full frame rate, or at all.
And it's easier and more power-efficient (because of hardware video encoding) to use screen sharing instead of sending drawing commands etc.
That’s cool. It would work for the mirror display functionality, but handover is more like CRIU in the sense that it becomes a process on the target host. Moreover headphones are also switching. So it seems a bit more involved than either.
For stateless processes, probably, but there are non-trivial problems reconciling state - think of your IDE / vim along with maybe a debugging session of another process. You need a lot of things in place to enable this use case for productivity goals. This is not an uncommon scenario for the current audience (I use AVP almost exclusively for work and think many users are engineers).
There may be simplifications to this, but I suspect it eventually lands in a distributed system problem involving state and strong consistency semantics. I’ve done this for most of my engineering career and all I can say is that they are fun problems to work on because they are some of the most difficult ones :)
Assuming you're an engineer, have you thought about what handing over a "window" from one computer to another actually entails? CRIU can do checkpoint/restore at container/process level - but you actually want it to run on both, no? So you need to split off just the I/O, but at the OS-level per window.
Apple has been doing a lot of work in this direction and they have stuff that actually work (like video calls and to some extent windows. These are processes running on different OS-es with a matrix of hundreds of devices.
It's not something you vibe code over the weekend.