Hi all, KWin developer here. This is quite the long thread… Let me add even more!
The color management protocol is IMO pretty close to being in a state where it can be merged; my goal is to finally get it merged in the next few months and ship it in Plasma 6.2. If there’s anyone in here that’s interested in pushing it forward, we already have two compositors implementing it, but if you implement it for any application that does color management, it would help a lot. For testing app side implementations, Plasma 6.0+ ships with an implementation of a tag of the protocol that’s supported if you set the KWIN_ENABLE_XX_COLOR_MANAGEMENT=1 environment variable for KWin.
If there’s any authors of applications that won’t be ported to be Wayland native any time soon, we can make (specifically, bigger than sRGB gamut) color management work with apps running through Xwayland too, as long as the app adds support for some custom X11 atoms on their windows. If you want to go down that route, please talk to me! The KWin side wouldn’t be too complicated to implement at least…
For the profiling part, that is indeed still a big issue, but @betazoid is right, if DisplayCAL / ArgyllCMS didn’t try to set calibration curves, the resulting profile should be correct - as long as the user makes sure HDR isn’t used, no ICC profile is set in the system settings, night light and similar effects aren’t active, all surfaces effectively get pass-through to the display. Last time I tested this, IIRC it seemed to assume it could apply a gamma 0.95 calibration curve, so the result was incorrect.
Mind you, that has been a while ago and with possibly messed up settings. I’ll try again with an up to date DisplayCAL very soon; if someone here already knows where that default calibration curve might’ve come from or how to make sure it doesn’t do that, I’d be happy about some pointers in the right direction 
As far as my understanding of the calibration curves goes, they don’t appear to make any sense in a full color managed system - their inverse gets baked into the TRC of the profile, so when KWin applies the profile, it just ends up not doing anything at all. If that’s incorrect, please someone correct me.
In total, all that would be necessary for DisplayCal to be a pretty good experience on Wayland with minimal effort would be to make sure it doesn’t try to apply any calibration curves (and ideally hide the relevant UI from the user), and to have some integration with the compositor to un-set the active ICC profile, night light and similar. For the latter, if anyone wants to make that happen, I’d be more than happy to type up a small Wayland protocol and the implementation in KWin for that purpose.