So let me give my view on this as one of the packagers involved with Fedora KDE packaging. (Please note that these are my personal perceptions, I am not speaking for Fedora as a whole or even the Fedora KDE SIG as a whole.)

As I see it, we definitely share some of the problems. Some are less drastic in Fedora though, and some are entirely specific to Kubuntu.

> Patches
This one, we of course have, too. We also have policies discouraging patches, but we also end up carrying some for various reasons.

> Symbols
Silent ABI breaks are indeed a major annoyance. Around here, we do not really have the tools to automatically detect those, so we more or less just punt on this issue, i.e., we basically do 2 things:

1. If things are released together (as kdelibs and kde-workspace were in the Software Compilation times), we always try to build the applications against the matching libraries, and use Requires with '=' versioning for known repeat offenders to forcefully version-lockstep them. (This used to be the case for kde-workspace and kdelibs before the permafreeze.)
2. All the other cases are handled in a purely reactive way: If people report crashes, we rebuild it.

> Copyright
Fedora is also a very picky distribution on this issue, but we handle things in a somewhat different way. We do not ship a "copyright" file. Instead, we ship each upstream COPYING file (in fact, we are required to ship the GPL COPYING with every single GPL-licensed package, the only exception being if it Requires another subpackage of the same source package that already ships the license; in fact, this is actually required by the GPL if you read it closely!), and a one-line License tag which lists the names of the licenses involved (which should be preceded by comments saying which license applies to what parts if there is more than one). But to fill in the License tag properly, we also need to check the licenses of all the files in the tarball. We also need upstream to ship the COPYING files for all licenses involved, which is way too often not the case. (Our guidelines say that we do not need to add missing COPYING files if upstream does not ship them, but that we should report it to upstream and try to get them to add the files in future releases.)

> Descriptions
Here, we found:
%description
%{summary}.
to do wonders. ;-) (To those who don't understand RPM: This just takes the contents of the Summary tag, adds a dot at the end, and makes that the description.) But of course having a real description would be better. This is something where we could try to work together in a better way, rather than every distro reinventing the wheel.

> Multiarch
For this, we use FHS multilib (/usr/lib64) rather than Debian multiarch (/usr/lib/x86_64-linux-gnu). We also actually multilib all our libraries (in particular, all the 64-bit libraries go to /usr/lib64), which means we don't have to figure out what should be multilib and what not. We do sometimes have multilib-related issues though, mainly stuff that hardcodes "lib" as the install destination, which should at least use lib${LIB_SUFFIX} if it isn't going to use the LIB_INSTALL_DIR. We also try to have -libs subpackages for applications that include shared libraries, so that we don't end up with the entire application getting needlessly multilibbed by our repository compose tools (i.e., we don't want to unnecessarily have e.g. amarok.i686 in the x86_64 repository).

> Splitting up Packages
This is something we've been increasingly doing now. In some cases, it got forced on us because upstream split the tarballs, but even where they didn't, we have moved to doing more splits recently. (User requests for it have always been there, and with most of the monolithic modules gone, the arguments for keeping the remaining ones unsplit are not as strong as they used to be.) In some cases like Calligra/KOffice, we have been doing split packages for years though.

What we do not do in Fedora is to split out every library and to give it a package name that includes the soversion. RPM does automatic Provides and Requires on sonames, so it will already enforce that we get the correct soversion without encoding it in the package name. And in Fedora, we try to avoid shipping multiple versions of the same library whenever possible; instead, we try hard to get everything to build with the same version, even if it means backporting or reverting some patch(es). We only ship compatibility versions of a library when it really cannot be avoided, and then we only suffix the non-default versions of the library with a version number, and we use a user-readable version number rather than a soversion, e.g., the KDE 3 kdelibs is kdelibs3, not kdelibs4.

As for the Breaks/Replaces/Conflicts stuff, we do not have a distinction between "Breaks" and "Conflicts" in RPM. RPM does not handle configuration the way dpkg does with debconf, so there is no such difference to be made in RPM. We have Obsoletes (i.e., your Replaces) and Conflicts. Otherwise, the usage is very similar. But at least in KDE packaging, we do not really run into the issue you describe with backports because we'll typically backport the file moves, too. (We are allowed to do packaging changes in updates as long as the upgrade path is reasonable, i.e., as long as our users do not end up with some of the stuff they had installed magically removed.)

> Debian Merges
This is an issue that we do not have in Fedora. The RHEL packagers probably share some of your issues (with Fedora as the upstream distro instead of Debian), but as a non-Red-Hat Fedora packager, I cannot really relate to that.

> Stable Release Updates
> Backports
There, the Fedora policies, even though they have become more stringent than in the past, are still much more lenient than yours. We are allowed to push bugfix releases of any package by policy. We also have an allowance to push feature releases of the KDE SC (and by the way, the kernel also gets updated with feature releases in Fedora). I think the plan for KF5 is that we'll just push all the new releases as updates. Assuming they don't bump their sonames, we will probably be allowed to do that, especially considering that no bugfix-only releases are planned. (Soname bumps are not entirely impossible, but a lot harder to argue for, especially if they mean rebuilding dozens of packages as a grouped update. The guidelines definitely strongly discourage them.)

> Crack of the Day
This is something we haven't really been looking into. We do not currently have such a service, nor am I aware of any plans to put one up in the near future. The people working on Plasma 5 packaging for Fedora have been manually doing some preview ISOs with Plasma 5, but the packages only track the releases (not daily snapshots), and the live images are then built manually from those packages.

> Co-installability
This is also important to us, thank you for the work you did on this issue!

> Automated Testing
I must admit that most of the KDE packages in Fedora still don't run the testsuites. And if tests fail in a Fedora package, the "fix" is typically to add "|| :" to the invocation.

> Obscure Architectures
Fedora currently has 3 primary architectures: i686, x86_64 and armv7hl. All other architectures are secondary, i.e., if our packages are broken on those, it does not break the primary architectures. In theory, secondary architectures are entirely the responsibility of the secondary architecture maintainers, but of course, in practice, we will try to help them get our packages work. That can indeed be quite a mess. (s390x can be particular "fun", for example.) For the primary ones, we are of course on the hook for fixing any issues. (One major annoyance there has been the qreal=float nonsense on ARM in Qt 4. Thankfully, that has now been fixed in Qt 5, qreal is now double by default everywhere in current 5.x releases. But it's of course too late to clean this up for Qt 4.)

> Future Changes
Fedora is also seeing changes right now (the "Fedora.next" plans; and no, I don't know whether that term came up before or after "Plasma Next" ;-) ) for which we're still trying to figure out how they affect us KDE packagers. In particular, Fedora is now going to focus on 3 Products (a Workstation based on GNOME 3, Server and Cloud), and we would like a fourth, KDE-based, Product. The outcome on that is still open.

> ISO Testing
In Fedora, KDE Plasma is a release-blocking desktop environment and so we get tested under the same process as Fedora as a whole. There is a bunch of testcases that the images have to pass. This forms a matrix, with the test cases as lines and the images to test as columns. This matrix is filled in manually by people testing the images. If the matrix is all green, the release is obviously good to go. If not, the QA team decides what counts as a blocker, what is eligible as a freeze override while waiting for the blockers to get fixed, and what is just not worth the risk of an attempted fix at all. There has been some talk of automating QA for a long time in Fedora, but most of the QA is still done manually around here.

There are some additional issues we encounter here in Fedora:

Shared Dependencies

I'm surprised you haven't brought up that one as well, given that you also draw from repositories shared with Ubuntu [Unity].

One problem we have had more than once is that some core system library got upgraded in Fedora because GNOME required the newer version, but KDE was not ready for it yet. The solution was almost always some ugly kludge. For PolicyKit 1, we ended up shipping the GNOME authentication agent even for KDE for a release because the KDE one wasn't ready yet. For NetworkManager 0.9, Fedora 15 shipped with a really ugly hack where they patched a compatibility API emulating NetworkManager 0.8 into 0.9. The big problem was that every NetworkManager update that was pushed to Fedora 15 (and there were many) would break one of the 2 APIs (while fixing the other, so the users of the desktop environment that was not affected would all give positive feedback to get the update rushed out to stable and the other would break). In addition, the compatibility API supported only what the snapshot of Plasma-networkmanagement shipped in Fedora 15 GA happened to use; so, when support for system connections was added in upstream Plasma-networkmanagement, that could not be used. We ended up pushing an update to something that used the real 0.9 API as soon as it became available (despite some known issues with migration of settings; after yet another NetworkManager update totally breaking the compatibility API, it was just not possible to wait anymore), and a later NetworkManager update dropped the compatibility API entirely. That was a lot of churn in a stable release. For BlueZ 5, we had to ship Fedora 20 with a prerelease of the new BlueDevil that had some bugs; those should now be fixed in post-release updates though. (That was probably the nicest solution, but in the other 2 cases I mentioned, not even such a prerelease was available for us to ship.) In less drastic cases, we sometimes have to backport support for a newer system library in some application from master.

With the post-release updates that we do, we sometimes have the opposite problem, i.e. that the new version wants a newer system library than what we have available. There too, the solutions vary. Sometimes, we can just upgrade the library along with the KDE application that requires it. Sometimes, we can get the application to build with the older library by reverting some patches. And sometimes, we just do not push the new version because of the dependency issues.

Patent-encumbered Dependencies

This one probably affects us more than any other distro. Please, oh pretty please, do not depend directly on something like FFmpeg! For multimedia, please use GStreamer 1 (for KDE applications, probably through an abstraction, i.e., through either Phonon or QtGStreamer), which handles all codecs as plugins. That way, we can just build your package without worrying about patents, and users can plug in the codecs they want from a third-party repository (once for all applications!) and they'll just work. And yes, GStreamer can do encoding, decoding, transcoding (yes, even from file to file), streaming in both directions and more. If you depend directly on FFmpeg, then we can only build your application without FFmpeg support or not at all. Similar considerations go for any other dependency known to be patent-encumbered, but FFmpeg is the prime offender there.

Non-Free Dependencies

In a similar vein, please do not depend on libraries that are not Free (as in Speech) Software. For example, for a long time, we were unable to package Simon because it relied on HTK, which is not even redistributable. (Simon also had a mandatory dependency on Julius, which comes with a custom BSD-style-but-not-quite license. The freeness of that license was also unclear, but it was eventually ruled to be acceptable for Fedora.) These days, Simon also supports PocketSphinx which is Free Software and can replace both HTK and Julius.

Even if the dependency is optional, it still means that Fedora users will not be able to use the features that rely on the dependency.

Bundled Libraries

One thing Fedora really does not like by policy is bundled libraries. Please never bundle libraries, whatever the reason. You are just making us extra work, because we will have to package the library separately anyway, but now in addition we will have to get rid of your bundled copy. The worst is patent-encumbered or non-Free bundled libraries, because we cannot distribute those at all, so in that case, we actually have to unpack your tarball, rm ‑rf the bundled crap and repack the tarball! That is something we really hate having to do. (For bundled libraries with acceptable licensing and without patent issues, we can rm ‑rf them in the %prep step of the specfile, but for encumbered stuff, that is not sufficient.) In short, there's not much that annoys us more than a 3rdparty/ffmpeg directory, please don't do that!