> It's not just the mnemonic, it's also that the location on the keyboard makes ctrl-c "prime real estate" so to say

Considering the hotkeys for xut and vaste, I think it's safe to say the mnemonic accounts for zero of the decision and the keyboard location accounts for all of it.

Win+c works too on windows. So does ctrl+insert/shift+insert on the terminals I just tested (cmd.exe, microsoft terminal with tabs, git bash, blue powershell terminal).

Win+c/win+v looks like a good compromise, using the Windows button for OS/DE commands, instead of application commands.

On terminals, the control key masked off the 6th and 7th bits of the 8-bit value sent by the letter key. That's a bitwise AND with octal 037, or in decimal subtracting 96 from the lower case key value. This happens in the terminal (or keyboard) itself, so the computer doesn't see it as two pressed keys, it just gets the masked value. In ASCII 'c' is 99 (decimal), so when modified with control is 3, ETX (end of text), which teletypes used to indicate the end of text. So unix shells reused that control character to terminate the current program with SIGINT. But every letter key maps to a control character at the start of the ASCII range, like 'g' maps to BEL for the bell, or 'h' maps to BS (backspace). '[' maps to ESC (escape) which is handy when Apple decides to move the escape key on their laptop keyboard.

Alt-F4 is pretty reliable on Windows, but it's not as catchy because no one likes craning their left hand to reach the function key (even though you could just hold right Alt).

The V isn’t arbitrary. Apart from the close location on the keyboard, the V looks like the handwritten mark often used to insert text in a physical document. This is similar to how the X suggests crossing out something.

On a US keyboard where these shortcuts were developed, you'd have to stretch your hand across the keyboard to reach Ctrl-P. That's why it's Ctrl-V, it wasn't arbitrary.

I miss Sun keyboards and their dedicated copy/paste keys.