I certainly intend to delete it on wayland.

The case there is very different though, as a client providing a small icon would have it upscaled.

X IMHO isn't worth the risk. There's clearly some need or it wouldn't exist in the first place.

Do you have any details on what the need is or was? I've been using a hardcoded cursor size to work around these issues since I started using Plasma and I've never seen any issues.

I don't

Edit! Of course I do.

Pragmatically it means don't set the XCURSOR_WHATEVER env var.

It's the default state, that you're in before doing anything else, (fwiw kde-workspace 617b08f5f6652bb9d918abc963954723caca59d2)
So it's sort of analogous to the "system default" we used to have in the fonts KCM.

We changed that to make specific values effectively be the default font anti-aliasing settings, for similar reasons (it was buggy and confusing). Could we do the same thing for the Cursors KCM?

I specifically chose that example as it got at least one angry bug report as soon as we removed it.

But at least this time we're not competing with another config, so it might be smoother. We'd need to do some research

If I understand it, the angry bug report came from the fact that we were actually setting new defaults ourselves, overriding the system-provided defaults, if any. For this, could we just remove the "Resolution Dependent" setting in the UI and make the state when $XCURSOR_WHATEVER isn't set effectively evaluate to a 24px cursor size (or whatever)?

I would suggest we have the KScreen KCM change the cursor size when you apply screen scaling, e.g. use 48px on 2x scaling and then nuke this setting. "My cursor keeps randomly changing size depending on where it is" is coming up every now and then.

Some tech notes:

The env I was referring to was XCURSOR_SIZE
We also have the X call XcursorSetDefaultSize(display size); I don't know what this does internally
We also have an entry "Xcursor.size" inside xrdb

Qt XCB uses XCursorGetDefaultSize
QtWayland uses XCURSOR_SIZE