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.