That certainly wasn't my impression from the mailing list. There are certainly some challenges with incorporating colour management into Wayland's model, but they also seem quite solvable (and the mailing list discussion seemed to end up with a solution).
Meanwhile the discussion on pixls seems to be a bunch of people complaining either that it's not solved yet, or if it is solved it won't work the same way it does on X.
The only remaining point of contention on the mailing list came down to colour calibration: one party wanted an API that allowed setting a temporary display-wide colour profile for the purpose of calibration, as this is how it has worked before. The response from a Wayland developer was that there should be a dedicated calibration extension that would allow setting a linear colour space for a specific region (eg. one matching the display). One of the reasons given for this is so that if the calibration application crashes, it doesn't leave the display in a bad state.
My understanding of the full solution is that applications would be able to specify a colour space for each buffer, and the compositor would do the appropriate transformation if that colour space does not match the actual display. Furthermore, there would be events given to the application when a window leaves/enters a display so that it can (if it wishes) choose to handle the colour space transformation itself by setting the buffer to use the same colour space as the display it is currently on. This means you get approximately correct colours when moving a window between displays, even before the application has had time to repaint itself, whilst also allowing the compositor flexibility like reusing the same output on multiple displays, displaying a preview of a window, etc.
I'm curious about this as well, but wouldn't be pointing fingers at the Wayland developers. See, for example, one of the most recent comments in the discussion linked to in the parent post, by Nilvus, one of the (wise and knowledgeable) darktable developers:
> The only thing is that color management for Wayland is progressing and far from being completely done. Even if work is quite slow, things seems to go in good direction. For correct and complete Wayland color management, we just have to wait again.
I can't find any reference to color management in the Blender meta-issue at https://developer.blender.org/T76428. For X11, I believe applications would have to manually determine the color profile of the display holding the current window, then query colord or and X atom to determine the profile. The application would then manually do the colorspace conversion. Does querying colord and making an in-application conversion works for Wayland until Wayland becomes colorspace-aware? Or if there are more wrinkles?
This is not a great summary. This discussion is full of people both saying wayland devs are clueless, having issues agreeing on any design in the same messages, and failing to actually present their case to upstream. It would probably go faster with less snark and us-vs-them.
See the discussion here: https://discuss.pixls.us/t/wayland-color-management/10804