Given that a lot of the use case is interacting with two different programs simultaneously, even just supporting it at the compositor level is pretty valuable: then it should "just work" for that use case. You can't really do a whole lot about the fact that most Wayland clients are making assumptions about seats; well, you can, but that's a lot more work...

> It's actually a lot more work than you'd think to support this...

Like: how would one support multiple keyboards? Is there an experimental or logical model for that?

I keep thinking of trying to see how far I get re-doing Niri in River.

The one other constraint that I'd really like to see relaxed is about displays, about being able to merge and subdivide screens as I please. Having a huge ultra-wide display really would be so much better if I could divide it up somehow. This is kind of the headline feature of stilch, which is a pretty neat compositor, https://github.com/wegel/stilch .

Niri has some tickets on it too. Merging monitors into a big display, and splitting a display (moments before the multi-pointer ticket was filed in Niri), https://github.com/niri-wm/niri/discussions/1285 https://github.com/niri-wm/niri/discussions/3160

There's been all kinds of rough incredibly hard things going on with Niri just trying to figure out how to handle some of the more interesting copy-paste scenarios, and with really weird sequencing issues across basically ephemeral inputs, that have really plagued the project and made life incredibly bad for downstream apps. This is just my opinion, man, but I think the lack of ambition about these ridiculous over the top features eventually starts hampering what turns out to be relatively prosaic asks. Better models for multi-seat, multi-cursor help scenarios like remote-desktop, and video-chat remote control, that at first don't seem needed, but are fundamentals that pay dividends if you shoot for them.