By this argument now that GTK supports directly rendering vector fonts sharply at arbitrary pixel densities we should switch back to bitmap fonts so GTK fonts can be bitmap rescaled again. I.e. the recent GTK reckoning you're referring to is actually about avoiding an extra raster rescale for exactly the reasons quoted, not about wanting more of it.
Why can't GTK be asked for the pixel size the display server needs instead of converting them to yet another vector format and rendering them on the display server?
The display server needs to be able to render the cursor or decide the cursor information even when no GTK (or other) apps are running. When it does so it needs to change the size of the cursor based on the display it's on. This size may not always be a whole number of pixels and may or may not change in the middle of a session. If you ever did cursor effects like macOS scaling the cursor on fast movement you'd need a way to handle that per frame size change request as well. In all it just doesn't make sense to move the logic for rendering the cursor into application frameworks.
I think it'd be best if "another vector format" was really "another cursor format which allows the actual cursor data to be tagged with a format". That way every time someone wanted to change the cursor protocol to allow compressed bitmaps or animated files or different vector formats it didn't require a whole new cursor file format to do it. Think something like MKV but for cursor data.
