First, I am completely against this 2 or 4 day turnaround time demand before taking over a package. Version bump uploads by a trustee are fine, but taking over a package should be a matter of months, not days.
I also agree with what João says here, and do the same myself. The one place this breaks down is when you want to push your package to hackage. In that case, you need a way of specifying a dependency that will allow your package to work until the upstream breakage is fixed by a maintainer. I can think of two options, both of which need some tooling help to be palatable, but maybe now is a good time for straw men.
One: depend upon a repository rather than a package on hackage. You can list a tag on your github fork of an upstream package as a dependency until a new version is pushed to hackage. I don't think this works now, and it opens a can of worms about supported version control systems, archival availability of those repositories, and overall duplicates some amount of the decision making that already goes into hackage.
Two: push a fork to hackage, but make it easier for a package author to hide (maybe eventually delete) a package from the hackage listing. We don't want to crush the package name space with every name suffixed with every developer's initials, but such a package can play a useful transitional role. This role's usefulness comes to an end when a maintainer upload is made, at which point one could prune the temporary name from the hackage listing. This hiding should be transitive, so the versions of my package that depended upon this temporary package would also be hidden, but the limited timeframe of these fixes should limit the impact.
I prefer option two, but it perhaps suggests a more pressing need for different ways of listing or searching hackage. Perhaps having a tag or category for temporary or personal forks that aren't included on the main list would meet this need.
Thoughts?
Anthony