Here is a log from IRC ubuntu-devel where Collin Watson said some things.
Bottom Line: you have to install a Clipboard Manager but Ubuntu is not currently planning to install one by default. Installing a Clipboard Manager is not seen as a workaround but as a solution.

Technically it is a bit more complicated than you might think (see information about SAVE_TARGETS) and what GNOME currently does is including a Clipboard Manager on an Opt-In basis (that is your application can request to make use of the Clipboard Manager) thus leaving all legacy applications, KED applications, Desktop agnostic applications remain broken.

(18:53:24) The topic for #ubuntu-devel is: Lucid Alpha 2 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
(19:01:21) nailora: there is bug 11334 that i am following for quite some time because it bugs me, too :) it is about what happens to the clipboard contents when an application quits. discussion has become more and more off-topic, and there seems to be a lack of developer participation. i'd like to know how to proceed with this...
(19:01:25) ubottu: Launchpad bug 11334 in ubuntu "MASTER Copy-Paste doesn't work if the source is closed before the paste" [Wishlist,Confirmed] https://launchpad.net/bugs/11334
(19:04:26) nailora: it is somewhat broken deep within the x-server (or the spec the x-server follows). or nearly all application just do not to the right thing as it can be fixed on application level, too. but this will not happen for all legacy applications. clipboard managers are not the solution but a workaround, but waiting for a solution in x.org/the spec x.org follows will take lots of time and a workaround might be good in the meantime... ...
(19:04:51) genii: I have Intel Pro/1000 XF (fibre optic card) ethtool is reporting only 1000 Base T (copper) capability (when should be 1000 Base FX). Is there some known prob/fix for the e1000 driver?
(19:05:21) cjwatson: nailora: workaround: use a clipboard manager application, that takes a copy of the clipboard contents and stashes it
(19:06:28) ***pitti reenables hourly WI tracker updates, sorry
(19:06:42) cjwatson: it's an X design issue, I wouldn't expect it to be fixed any other way
(19:06:57) cjwatson: indeed I don't think it is *fixable* any other way
(19:07:00) nailora: cjwatson: i know that and i do it it that way personally. but arguably this should "just work" for everyone. that would require a solution that could be included in the default installation
(19:07:27) cjwatson: if you're starting from the position that "clipboard managers are not the solution but a workaround", then there is no other option except to wait for (or participate in?) an X design fix
(19:08:43) cjwatson: X clipboard clients ask the clipboard owner (an application) for clipboard contents when they need it, and if the application exits then there's no owner to respond; there's no way that can be an application bug
(19:08:59) chrisccoulson: which applications don't work correctly?
(19:09:13) chrisccoulson: i could only recreate that with firefox, and that's been fixed upstream recently
(19:10:20) cjwatson: maybe something is managing the clipboard centrally now?
(19:10:30) nailora: it seems that upon exiting an application is able to ask the x server to preserve the contents somehow (most gnome apps and notably firefox nowadays do it). so it can be fixed on application level
(19:12:15) jdong: isn't that something introduced way bac: http://library.gnome.org/misc/release-notes/2.12/#rngeneral
(19:12:29) ***cjwatson is just five seconds late with the same link
(19:12:51) chrisccoulson: the clipboard is still based around the selection mechanism
(19:12:51) nailora: but most apps simply do not do that. and somehow it seems redundant that you have to request this "feature" if i cannot think of a situation where you would not want it. so it should be default to save the contents and thus be handled in x.org (even so contents from crashing applications would still be lost that way).
(19:12:59) cjwatson: gnome-settings-daemon, apparently
(19:13:07) chrisccoulson: but applications that don't work explicitly destroy these resources when they close
(19:13:45) nailora: therefore i think a push solution (instead of pull like now) is in fact better (and clipboard managers are basically transforming it from pull to push)
(19:14:57) cjwatson: nailora: do you have evidence that applications need to explicitly request this feature?
(19:16:32) cjwatson: the current state appears to be basically just a clipboard manager built into gnome-settings-daemon
(19:17:13) cjwatson: I don't see any application-level requests going on - gnome-settings-daemon responds to various X events
(19:17:28) nailora: however todays clipboard managers are to much bling bling. they should run in the background, have no gui, just make things work. history and stuff like current implementations offer could optionally be added for power users). and something sensible should be done with binary data in case applications offer different content depending on the receiver (notably the gimp does this). these things could be fixed easily. but no developer commented yet or said something like "just fix these problems and it will be included in main"
(19:17:44) cjwatson: nailora: gnome-settings-daemon's clipboard manager runs in the background, with no bling
(19:17:56) cjwatson: no UI at all AFAICS
(19:17:58) nailora: no i have no strong evidence, it is just how i understood the discussion in the bug
(19:18:13) cjwatson: you're making some assertions that don't seem to match how the code works
(19:18:37) cjwatson: at this point, I imagine that developers are put off commenting on the bug simply because it's one of those enormous unmanageable bugs
(19:18:50) nailora: cjwatson: gnome-settings-daemon's clipboard manager does not seem to fix all problems
(19:19:01) cjwatson: this is why bugs need to be kept small and focused, and why jumping into an existing bug to expand its scope tends to be harmful
(19:19:48) nailora: so you basically are suggesting a new bug should be opened containing a short&precise list of applications that are still broken and an overview about the possible solutions?
(19:19:52) cjwatson: ah, let's see, there's a SAVE_TARGETS request
(19:19:57) cjwatson: not suggesting that at all
(19:20:21) cjwatson: I'm suggesting that, if it works for many applications, there ought to be a separate individual bug against each application that seems to have a problem in conjunction with the clipboard
(19:20:28) cjwatson: grab-bag bugs are fundamentally doomed
(19:21:02) cjwatson: apologies for not noticing SAVE_TARGETS before now, that supports the application-request assertion you made
(19:21:53) nailora: installing a clipboard manager by default would have solved all the issues so it was not unreasonable to group it at that time.
(19:22:36) cjwatson: it may not have been unreasonable, but it was never going to work well :)
(19:22:50) nailora: when favoring the fix-every-application-solution this massive collection is counterproductive 
(19:23:06) cjwatson: http://www.freedesktop.org/wiki/ClipboardManager seems to be the closest thing that's going to happen to a spec-level change
(19:23:12) nailora: but it seems as if this is not a simple "bug" but something that needs more discussion
(19:23:28) nailora: has been featured in forums & brainstorm too
(19:23:39) cjwatson: it seems reasonable to file separate bugs against individual applications (presumably non-GTK applications, for the most part? don't know about Qt) that don't support it
(19:30:26) nailora: just tried dolphin and it fails :)
(19:32:55) nailora: so yeah, perhaps all qt-apps could be fixed with one change. this would be a big improvement but still leaves a lot more apps. but it shows why the "applications can request this feature" is the wrong default imho. apps should be allowed to opt-out but have it enabled by default because that way data loss is prevented.
(19:35:21) slangasek: pitti: sorry about that; ifupdown reuploaded
(19:39:28) pitti: slangasek: ah, thanks; what happened there?
(19:40:22) slangasek: pitti: ifupdown hadn't been rebuilt with the karmic-final version of debhelper, so this conflict went unnoticed; was already fixed in lucid, but I'd forgotten about it and didn't do a test install of ifupdown on karmic before upload, thinking it was a trivial change :/
(19:41:04) pitti: I suspected something like that when the problem was reported, but it wasn't obvious that something like that could happen when I reviewed the diff
(19:41:06) pitti: thanks for the fast fix
(19:41:18) pitti: I'll check/accept it right away
(19:45:21) slangasek: pitti: ta!