@evgandr @daltux @phoronix @librewolf

Except that middle-click was never quite paste from the clipboard in X11. Copy and paste in X11 was a mess. There were multiple selection buffers and middle click was always a paste of the PRIMARY buffer, which was normally set by the last application to select some text. Or, if that application exited, empty. The contents of the PRIMARY buffer went away if you stopped selecting it.

The CLIPBOARD selection was just another selection, but a separate X11 client (e.g. xclipboard) would take a copy of it when it changed and make it available even if the original owner stopped making it available. This was normally the thing that you did with a copy operation.

X11 also had CUT buffers that let you move things into the X server itself by making them properties of the root window. I've never seen that in the wild though, most things implemented cut as a combination of copy and local delete.

X11 traditionally used middle click to paste from the PRIMARY buffer. But a lot of users found that confusing, because accidentally selecting and then hitting the middle button would appear not to do anything (in fact, it would expose the current selection to the PRIMARY buffer, then paste it over the top of itself). So some toolkits ended up making middle click paste from the CLIPBOARD buffer.

So now you're in a situation where middle click will definitely paste from somewhere, but it's inconsistent about where.

Now you move to Wayland (or some other UI layer) that doesn't have this baroque combination. What should middle click do? It's inconsistent with previous behaviour whatever you do: if you paste from the clipboard then it's inconsistent with the traditional X11 behaviour and if you don't then it's inconsistent with the other bits.