I think when you restart the session the task manager is not black anymore. Can you confirm?

yes, I can confirm.

OSD shown when we switch between virtual desktops is also black.

1. enable "Show on screen display when switching" in system settings > workspace behavior > virtual desktops.
2. set another task switcher in system settings > Window management > taks switcher (I changed from Breeze to Large Icons)
3. switch between virtual desktops

I see a black OSD.

Operating System: Arch Linux 
KDE Plasma Version: 5.17.90
KDE Frameworks Version: 5.66.0
Qt Version: 5.14.0

task switcher also becomes black after I set a window rule.

Operating System: Arch Linux 
KDE Plasma Version: 5.18.1
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1

I can confirm this on an up to date KDE neon.

I tried several things for nothing to make it redraw its background. Like restarting plasmashell, changing the task switcher layout or colors/plasma/app style and so on. Sometimes I have a stretched blurry image of the last application window instead of the black background. But it is only kept until the next "switch".

It also happens when I change the font settings. In my case I switched the title bar font, clicked on "Apply" and after a short workspace flickering the task switcher is broken.

Created attachment 127696 [details]
default left-side task switcher

The same thing (black task switcher) happens if you open KDE's compositor settings, switch rendering backend, and press OK or Apply. My system setup is in bug 420450.

I suspect the task switcher turns black whenever it's reinitialized or something. Don't know what though. Might be worth poking at with a debugger and symbols, or editing and rebuilding.

*** Bug 420450 has been marked as a duplicate of this bug. ***

*** Bug 421129 has been marked as a duplicate of this bug. ***

Raising the priority as this makes affected non-default task switchers unusable.

*** Bug 422879 has been marked as a duplicate of this bug. ***

The default task switcher is also unusable on my system since the background is black, so you can't see which thumbnail is selected.

Created attachment 130547 [details]
Task switcher when changed to the thumbnail grid option

SOFTWARE/OS VERSIONS
Operating System: Manjaro 
KDE Plasma Version: 5.19.4
KDE Frameworks Version: 5.72.0
Qt Version: 5.15.0

The task switcher would work as intended only after re-logging into the user account or restarting the computer. If it is changed in the system settings again, it goes back to the black or translucent background colour.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/354

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/356

Git commit 292335beacfc07cca2d1db99e6ab01599024f664 by Vlad Zahorodnii.
Committed on 19/10/2020 at 09:13.
Pushed by vladz into branch 'master'.

Introduce persistent global share context

On Wayland, internal windows that use OpenGL are rendered into fbos,
which are later handed over to kwin. In order to achieve that, our QPA
creates OpenGL contexts that share resources with the scene's context.

The problems start when compositing has been restarted. If user changes
any compositing settings, the underlying render backend will be
reinitialized and with it, the scene's context will be destroyed. Thus,
we no longer can accept framebuffer objects from internal windows.

This change addresses the framebuffer object sharing problem by adding
a so called global share context. It persists throughout the lifetime of
kwin. It can never be made current. The scene context and all contexts
created in our QPA share resources with it.

Therefore we can destroy the scene OpenGL context without affecting
OpenGL contexts owned by internal windows, e.g. the outline visual or
tabbox.

It's worth noting that Qt provides a way to create a global share
context. But for our purposes it's not suitable since the share
context must be known when QGuiApplication attempts to instantiate a
QOpenGLContext object. At that moment, the backend is not initialized
and thus the EGLDisplay is not available yet.

M  +10   -0    platform.cpp
M  +14   -0    platform.h
M  +59   -7    platformsupport/scenes/opengl/abstract_egl_backend.cpp
M  +1    -1    platformsupport/scenes/opengl/abstract_egl_backend.h
M  +1    -1    plugins/qpa/eglplatformcontext.cpp
M  +5    -0    plugins/qpa/integration.cpp

https://invent.kde.org/plasma/kwin/commit/292335beacfc07cca2d1db99e6ab01599024f664

@Nate I'd like to backport the fix to 5.20 branch. However, I'm not sure about the final version where it'll end up (5.20.1 or 5.20.2). That's why I didn't specify Fixed-In:.

5.20.1 is tagged tomorrow. So if you cherry-pick today or early tomorrow, it'll make it into 5.20.1.

https://community.kde.org/Schedules/Plasma_5

And thanks for fixing this BTW. It was one of my personal Wayland blockers. :)

Git commit 445d1496e4a57d81dc86928e4f8b2385a73e6386 by Vlad Zahorodnii.
Committed on 20/10/2020 at 12:21.
Pushed by vladz into branch 'Plasma/5.20'.

Introduce persistent global share context

On Wayland, internal windows that use OpenGL are rendered into fbos,
which are later handed over to kwin. In order to achieve that, our QPA
creates OpenGL contexts that share resources with the scene's context.

The problems start when compositing has been restarted. If user changes
any compositing settings, the underlying render backend will be
reinitialized and with it, the scene's context will be destroyed. Thus,
we no longer can accept framebuffer objects from internal windows.

This change addresses the framebuffer object sharing problem by adding
a so called global share context. It persists throughout the lifetime of
kwin. It can never be made current. The scene context and all contexts
created in our QPA share resources with it.

Therefore we can destroy the scene OpenGL context without affecting
OpenGL contexts owned by internal windows, e.g. the outline visual or
tabbox.

It's worth noting that Qt provides a way to create a global share
context. But for our purposes it's not suitable since the share
context must be known when QGuiApplication attempts to instantiate a
QOpenGLContext object. At that moment, the backend is not initialized
and thus the EGLDisplay is not available yet.
(cherry picked from commit 292335beacfc07cca2d1db99e6ab01599024f664)

M  +10   -0    platform.cpp
M  +14   -0    platform.h
M  +59   -7    platformsupport/scenes/opengl/abstract_egl_backend.cpp
M  +1    -1    platformsupport/scenes/opengl/abstract_egl_backend.h
M  +1    -1    plugins/qpa/eglplatformcontext.cpp
M  +5    -0    plugins/qpa/integration.cpp

https://invent.kde.org/plasma/kwin/commit/445d1496e4a57d81dc86928e4f8b2385a73e6386