Are you sure that MELPA has issues? I've been running with it since it started and one thing that I can say about it is that its been a joy to use. Hats off to milkypostman & sanityinc for maintaining it.
If you do have an issue, I suggest you open it on MELPA's GitHub issue page and I'm pretty confident that you'll get a quick response.
As for tweaking Emacs' config, yea, I have to admit, I've spent time on it too and things can always improve.
The issue Melpa has is that it builds from HEAD, whereas many package authors treat HEAD as a working state that should not be used directly. Melpa doesn't (or didn't last time I checked) have support for building off tags or non-master branches, which would solve this. And if I remember correctly, when I raised this issue, he disagreed on some philosophical grounds. So it's an inherent problem in Melpa.
On IRC we get a steady stream of confused users (in both the #emacs and #clojure channels) who added melpa because some library recommended it in their readme and they didn't realize it would cause every package they use to also pull from the unstable branch. It is a huge support headache.
However, these days I only very rarely find packages that aren't available on Marmalade. When I do, it's usually enough to ask the maintainer nicely and they start publishing to Marmalade; it's not a difficult process by any means.
But one of the issues with Marmalade is that anybody can fork your project (patch it or not) and just push it. With MELPA, they try to get the original authors to submit the projects. If you've got patches, they are pretty strict about it and encourage you to get them merged in the package rather than accepting a fork.
Hmm. Is there a particular repeated source of breakage? I only use MELPA, and apart from the recent nrepl->cider migration (which was intentionally piloted on MELPA) I've not had any instances where my work was hindered by package issues. And as a maintainer, I update my packages daily.
Or a feature. ;-) Don't forget that el-get has been popular for years, and it pulls dev versions of libraries. I don't see any compelling evidence that breakage is more frequent for MELPA users than for those who only use Marmalade.
It's correct that we don't want our current packages to build off non-master tags or branches, and that's because we've a bigger picture in mind. It's a concrete goal of MELPA is to provide two parallel archives of packages: the existing one, filled with "bleeding edge" packages, and a new archive containing "stable" packages which have been built from the same upstream sources, but using existing version tags found there. We're making progress with this goal: see https://github.com/milkypostman/melpa/pull/1407, for example.
If we can pull this off, this will yield the best of both worlds: users will get known-good versions of packages, and at the same time they will be confident that the stable packages came from the upstream developer's source tree (which isn't at all assured with Marmalade). It will also make releasing a new stable package as easy as tagging a source repository.
Recent versions of `package.el` allow packages to be pinned to specific package archives, which lets those concerned about bleeding-edge breakage pick and choose between "stable" and "unstable" packages on a case-by-case basis.
If you do have an issue, I suggest you open it on MELPA's GitHub issue page and I'm pretty confident that you'll get a quick response.
As for tweaking Emacs' config, yea, I have to admit, I've spent time on it too and things can always improve.