As discussed during Akademy 2019, here is my user story about what's needed to be able to use (seriously) Krita on Plasma wayland.

*Graphic tablet support*

To be able to use Krita, of course first we need good graphic tablet support, which brings a number of issues.

-Driver issue:
On X11, the preferred driver for (wacom) Graphics tablets is xf86-input-wacom , from the linuxwacom project. It provides all the necessary features to make the best use of wacom tablets for all kinds of users, through the command xsetwacom. You can find all the available parameters using the command xsetwacom --list parameters .

As this driver is tied to X11, on wayland the only option is to use libinput instead, which is much more limited in terms of options. So, one needed thing ultimately is to extend libinput to reach feature parity with xf86-input-wacom. I know this is not directly part of plasma dev, but this had to be said, and I hope we can get good communication with libinput devs to move forward on that topic.

-Plasma support of tablets:
Currently, on a plasma-wayland session, tablet does absolutely nothing, not even moving cursor (tested on Manjaro, with latest updates).

For comparison, on gnome-wayland, tablet works, showing a second dedicated cursor. When testing Krita on it, the main tablet cursor disappears and only shows the second "Outline shape" cursor on the canvas ; painting does work relatively okay with pressure and tilt support (still I have a feeling while drawing that the input is not exactly as good as when using the wacom driver, but I didn't test long enough to really explain the difference), and clicking on the interface buttons works but you have to blindly press them (as the Outline-shape cursor is only visible above the canvas area). Tested with Krita appimage version 4.1.7; the next 4.2.* versions have a bug that makes it impossible to click on most of the interface buttons, at least with the system stack used currently in Manjaro, both on X11 and wayland.

*Color management*

To be able to rely accurately on the screen colors, unless you have a very-very expensive screen that has perfect color output by default, one needs to be able to calibrate it, and/or use a specific color profile for the screen output.

On X11, the go-to software for this is ArgyllCMS. It provides tools to calibrate the screen and create a .cal file that can be loaded to said screen, and to create an .icc color profile (which is needed if the screen is calibrated to something different than sRGB) and to install said profile to the system.

I wrote a tutorial article in 2011 when I started to use it ( https://timotheegiet.com/blog/misc/argyllcms-trying-to-make-color-management-easy.html ), though nowadays I know that for my use case I only need to generate a .cal file to calibrate the screen to sRGB (using the dispcal command) and then load that .cal file to the screen (using the dispwin command).
I personally prefer to stick to sRGB as it makes things simpler for multi-screen mirror setup; as I want the same output on both the screen tablet and external monitor; and while it's possible to use different calibration for each, it is not possible to transform that output to different colorspaces, so I stick to sRGB which is somehow compatible with any screen.

This brings us to wayland. We need to have ArgyllCMS (or a new equivalent) to be able to measure colors to create a calibration file, and load this file to the screen output.
For other advanced use cases, we also need to be able to create an .icc profile and transform the screen output to said profile. In this case, for color-managed applications like Krita, they need to be able to fetch the color profile used for the output, and directly send colors adapted for that color profile, bypassing the desktop color transformation.

Note that this topic of color management is very complicated, so I welcome color-experts to complement or correct these explanation which I wrote from my personal user experience.

If you have any question or need more feedback, let me know.