Are there different paste buffers depending on how it's activated?
In most apps, the primary selection is populated merely by selecting something, while the clipboard selection is populated by some sort of explicit user action, like ctrl-C or a context menu.
The clipboard selection is pasted with some other explicit action. Usually it's analogous to the way you copy to it, like ctrl-V, or a context menu.
The primary selection is usually "pasted" with middle mouse button. Sometimes there's also a keyboard shortcut, and if there is it's often a modified form of the clipboard-selection's paste shortcut.
Most people get confused by the fact that there is more than one "clipboardy thing". They copy to one, and then paste from the other and winner why their copy didn't work.
The fact that there isn't a consistent action to get to each doesn't help. It is consistent if you stick to apps from the same "family" (eg: Gnome/gtk+ or KDE), except terminals never use ctrl key shortcuts. (Because control characters already mean something in terminals.)
This is one of the cases where I think the Mac approach happens to work out better than Linux (or Windows): by using ⌘ instead of control as the default shortcut modifier, there's no ambiguity about whether I'm talking to my terminal (copy, paste, spawn new window, etc.) or trying to send a control character. I don't know why the Linux community defacto-standardized on control keys rather than Super (or even Alt), given the high proportion of Linux users who are also terminal users.
Let's not blame the (l)users. For example, by merely selecting the text you want to replace you may override the paste buffer content - this is a blatant POLA[1] violation.
[1] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
I don't think stating that "people get confused" is placing blame on one party or the other. That they get confused is a fact. I said nothing about whose fault that is.
> For example, by merely selecting the text you want to replace you may override the paste buffer content
It's a trade-off. Having the mere act of selecting text copy it to the primary selection is extremely convenient. There isn't any way to have that convenience without the downside that overwriting it is also easy. If you want to copy something and not have further selections overwrite it, you use the clipboard. This is like the trade-off of having a confirmation dialog or not.
I wouldn't say "this is a blatant POLA violation". What surprises one person might seem obvious to another. There is only one intuitive user interface, everything else is learned.
The confusion starts with the fact that people typically aren't told that the primary selection and the clipboard are two separate things (and by using the term "paste buffer" to ambiguously refer to one of them you're perpetuating this). Much of this misconception comes from the fact that more popular systems (Windows and Mac) only have the one clipboard, and people assume that whatever they learned first is universally true.
Not knowing about the primary selection actually isn't a problem on its own, though. After all, if one only knows about the clipboard operations, but doesn't ever trigger pasting from the primary selection, then the fact that the primary selection even exists would be invisible to them. The clipboard selection on X works pretty much the same as the clipboard on other systems.
The real problems start when people who believe there is only one "paste buffer" are then told, or discover, that they can "paste" using operations that actually paste from the primary selection rather than the clipboard. The worst part is that this doesn't fail outright, but instead seems to work, but inconsistently. Now they're confused, because there is no way to reconcile this behavior with their mental model that "this is another way to paste from the one and only clipboard".
Only on terminal it's with SHIFT to avoid conflict the Ctrl+C that ends a command.