It shouldn't activate, but the window should be raised.

Correct, it's raised only, but I don't think it should. I have often a cascade of multiple windows open with only a small part looking out from underneath. 

Dragging stuff from one window next to this cascade to the top-most is then not possible because when moving the cursor over the small part of the lower windows raises it and covers the top-most one.

What could be done is raise it after the drop was done on the lower one.

In that case you disagree with most users. That windows aren't raised during drag and drop on X11 was one of the most often reported bugs.

Ah, I think I know now what I (and they) want: Raise the window, but only after a delay. Such that when you move the drag quickly across a small ledge of another window that is mostly behind your real target it does not directly raise the window in front of your target window.

Adding a delay could be an option.

I agree that windows shouldn't be raised, or at least not without a delay. If I have a maximized window in the background (such as KMail), and several smaller windows on top of it that I'm working with, it's impossible to drag and drop from one of these into another if they don't touch.

Well, it would be possible to activate the target through the task bar (if that didn't make Plasma crash on Wayland), but typically the visible windows are the ones I'm working with, and I'd rather go through the taskbar route in the less common case of dragging into an area of a window that is not visible.

KWin can even be configured in such a way that clicking inside a window doesn't raise it; with that setup it's weird that dragging over a window raises it immediately.

Git commit ad7a826ea13656bae19ad17dc812bcc8f3e6501c by Xaver Hugl.
Committed on 25/03/2021 at 12:40.
Pushed by zamundaaa into branch 'master'.

Drag'n'drop: only activate clients after still hover

M  +42   -5    src/input.cpp

https://invent.kde.org/plasma/kwin/commit/ad7a826ea13656bae19ad17dc812bcc8f3e6501c