there are a few problems that make this idea nasty: 1. input focus / window selection - lots of code relies on the idea that the currently selected window is a

there are a few problems that make this idea nasty: 1. input focus / window selection - lots of code relies on the idea that the currently selected window is a singleton, not 1..n_cursors. Adding support for multiple cursors breaks this assumption and code that looks something like active_window().do_something() would have to be biased against the selection tied to one cursor, breaking their independence. You'd ideally want a 1:1 match between keyboards and cursor input devices for this to be workable. 2. accelerated drawing - a very common (if not universal) display server trick is to separate mouse cursor rendering, own content (like window decorations) and accelerated content (like hardware video decoding and color keying) into different output planes with varying drawing restrictions. They update asynchronously in order to reduce memory bandwidth requirements and hide latency/jitter. The number of available such planes are typically low (1,2,4) and dynamic. Adding another mouse cursor breaks the simple '1 output plane @(last sample.xy) cursor.w*cursor.h' and forces either multiple planes to be consumed or the allocated plane size to be primary plane resolution size and updated every frame, which can impact other connected monitors and so on. 3. absolute vs. relative mouse samples / warping - this varies more between windowing systems but some applications deals with a mouse in terms of display- absolute, surface- absolute or device relative samples. At the same time, different mouse devices (touchpad, "normal" mouse, tablets, ...) provides samples in different types (device-relative, device-absolute) and someone needs to do the translation. This matters in situations like FPS games. 4. nested - it is not uncommon for applications to "hide" the global mouse cursor and then maintain their own inside the context of its windows. Games in particular like to do this, but also VMs and similar oddballs. Someone needs to do the translation and it typically becomes dx,dy = last_mp - current_xy then "warp mouse to window midpoint". 5. sample optimizations - some systems like to provide a memory mapped global mouse cursor position to keep storms away from window event loops (think gaming mice or drawing tablets with 1-2+ kHz sample rates being forced into relatively small event queues). There are hacks to work around all these problems but not in a universal "won't suddenly break for your use-case" way. The most common I've seen is simply to make the other mouse cursors into non-decorated transparent windows that they move around, check window underneath the 'fake cursor' and inject into window event queues...