The problem with that is that some apps never set PRIMARY. The experience will be just as confusing without more menu items.

Well then their application won't work in X11 on UNIX, so let's not worry about getting it to work on OSX. If selecting text doesn't change PRIMARY, then there's really no way for us to GET that selection.

For instance the Gtk+/Gimp image copy only sets CLIPBOARD. So the user may come to expect image copies to not work, but in reality they will work (if I get this code finished) but only be aware of that after switching to CLIPBOARD.

Right, and this will be handled "automatically" (ie, not with the Edit-

copy menu) when the user does 'Edit->Copy' in gimp, xemacs, openoffice, etc. (assuming that is what the user wants... hence the 4 options I mentioned in my pseudocode).

...

We should have an option that changing CLIPBOARD causes that to be proxies to pb. The reason being that users don't want to copy twice (once to CLIPBOARD then to pb). Additionally, most users don't understand what that would even mean.

I agree that most will not immediately understand what it will mean. But it's the kind of thing that trial and error could indicate. I wish there was a better way.

I think there is (what I outlined in my pseudocode)

...

The user almost never expects the copy action in our menu to copy CLIPBOARD.

Well, if they copy images, or have just done Copy in an X11 editor menu, they might expect that.

I think they'd expect that if they copy imaged or hit copy in an editor, the PB will automatically be updated. You should never need to do edit->copy (menu 1) then edit->copy (menu 2) to copy to the PB. Additionally, some users disable key equivalents, so actually forcing them to goto the menu is not desirable (hence the proxy on select and proxy clipboard options).

X11 Tk apps for instance use PRIMARY for the highlighted text, and an Edit->Copy usually copies that to the CLIPBOARD via [tk_textCopy]. Tk apps aren't alone in that regard either.

Yes. That's actually the expected behavior, and we want to support that (and not care about apps that break that convention).

XGetSelectionOwner can return 2 different windows if you have different PRIMARY and CLIPBOARD owners.

yep.