Here's an explanation why upgradepath currently checks just updates-pending, and not updates-testing-pending:
https://lists.fedorahosted.org/pipermail/autoqa-devel/2010-September/001189.html
https://fedorahosted.org/autoqa/ticket/231

But the most common package maintainers' complaints are not about gating updates-testing (that's what those explanations covered). Their complaint is that they receive the upgradepath result too late - only after they request a push to updates. They would like to receive the result immediately once the update is pushed to updates-testing.

I believe that's possible. We just need to decide how exactly it should work. Let's imagine this scenario:
* The same build (with just a different release tag) is pushed to F19-updates-testing and F20-updates-testing. Of course the F20 one must not be pushed into stable updates later than the F19 one, otherwise upgradepath would be broken.
Now what should be the result of upgradepath for the F19 update?
1. FAILED, because there is no pending F20 stable update and if the F19 was pushed to stable right now, it would break upgrade path. This behavior will annoy many package maintainers, because they are used to propose the same build into several versions of Fedora. Failures will require them to check logs, just to find out everything will be OK if they request stable for both updates in the same time.
2. PASSED, because the F20 update is not pending stable yet, but at least it exists. This has the disadvantage of sometimes providing safe assurance that everything is OK, when it might not be. If the package maintainers set karma autopush, and the F19 update is autopushed earlier, the moment it enters updates-pending, the result will change to FAILED, to their very surprise. OTOH, we will be able to inform about problems much earlier in this case. So, I feel there is an overall improvement over the existing state.

I think that 2) is much better and we should implement it. The algorithm would be:

        # Pushing PKG to F(N)-updates-testing means:
        #   1. PKG in F(lower)-main <= PKG to push
        #   2. PKG in F(lower)-updates <= PKG to push
        #   3. PKG in F(higher)-main union F(higher)-updates union F(higher)-updates-testing => PKG to push
        #   (-updates-testing also implies -updates-pending)

As a bonus: Can we do it even sooner, once the update is //requested// into testing? I think we can:

        # Pushing PKG to F(N)-updates-testing means:
        #   1. PKG in F(lower)-main <= PKG to push
        #   2. PKG in F(lower)-updates <= PKG to push
        #   3. PKG in F(higher)-main union F(higher)-updates union F(higher)-updates-testing union F(higher)-updates-testing-pending => PKG to push
        #   (-updates-testing also implies -updates-pending)

If we do this, the important part is that we must not forget to re-run the check once any of those updates are moved to updates-pending tag, with the usual "hard" criterion:

#   3. PKG in F(higher)-main union F(higher)-updates union F(higher)-updates-pending => PKG to push