Making the xserver the owner of all content is pretty much the same as using a clipboard manager and making that the owner of all content. There are working clipboard managers ready to be installed from the repository -- namely klipper, glipper and parcellite . they are the more or less official workaround as suggested by collin watson (see comment # 207 ) why none of these clipboard managers is installed by default goes beyond my understanding.

There is one problem with these clipboard manager that causes problems with programs like e.g. the gimp and other, that is quite hard to fix properly.

When exporting some lines of text to the clipboard the suggested approach (just grabbing it when it is exported) will work just fine. With binary data like images the problem gets more complicated because now you have a lot more data and it potentially contains lots of troublesome bits (nullbytes and the like) that must not crash nor confuse your clipboard manager. but that is pretty much solved by current clipboard mangers, too.

The real problem is about nonstatic data. In the above examples the content was present in the source application and you only had to copy it away from there. The clipboard offers functionality to create the data on demand. For example you could work on some vector graphic in inkscape and copy and paste the data to gimp where it would arrive as pixel data. The pixel data is only created when you paste it somewhere. So you can copy a hundred times and paste only the last copy, then only that version will be converted to pixel data. That is the clipboard basically asks your application to provide some content and it is up to you if you answer with some existing data or generate some new data just to satisfy that request. When that generation is expensive it is not practicable to do it every time something is offered to the clipboard but only when something is requested from the clipboard. But a clipboard manager basically request the data every time some data is offered to the clipboard invalidating that optimization and causing a lot of data to be generated and transferred.

That overhead might be tolerated, too. But to further complicate matters:
When exporting something to the clipboard you don't export something fixed. Fixed means you already decided about what to export (although you might not yet have created it yet -- see above). No, you say that you offer "plain text",  "rich text", "binary data" or "a nice picture". When pasting the application does not request the "contents of the clipboard" but says it understands "plain text", "vector graphics", "binary data" and "wave sounds". Now some arbitration takes place and the applications agree on transferring "plain text" (or "binary data" whatever is better for some definition of better). Thus it is not even clear what a clipboard manager should grab when an application offers some data for export to the clipboard. It might grab all the offered datastreams but that obviously means some heavy overhead...

One thing gnome does is to offer a clipboard manager where your application can store the things it offers to the clipboard when it exits. Control over the clipboard is then transferred to that clipboard manager. That way no data is lost and data is only copied when your application exits, minimizing overhead. This means each and every past, present and future application must be extended to make use of that manager (opt in instead of opt out or forced use of the manager). That is not gonna happen. Furthermore it will not work for crashing applications...

Conclusion: Why not go with a clipboard manager that grabs everything? And then working around the performance bottlenecks by stopping certain transfers from happening? You could offer an API to application to mark certain exports as not relevant for the clipboard manager and you could blacklist certain offerings in the clipboard manager for some cases where you cannot modify the application. You could even display a shiny notify-system message telling the user: "what you just copied will not be available permanently. Paste it now before closing that app!" That manager would support legacy applcation and should be installed by default so no user is bothered with this bug ever again.

How to implement: Patch glipper/parcellite to grab everything, offer some blacklisting to mitigate bottlenecks and talk to someone at canonical to include it in the default install...