This isn't a bug - Current policy is that the three supertester votes will only unlock a package for promotion after 20 days, rather than the normal 10. The idea is that the three supertester votes unlocking a package are a last resort to prevent a not-very-popular package being locked in testing forever, it's not aimed as a replacement to getting 10 votes.

Generally speaking, dependencies should be non-user packages so that theyre promoted automatically when the user package is promoted.

In cases where the developer for one reason or another has a dependency that's also a user package so needs separate voting however, I see two potential solutions:
On the ad-hoc side, maintainers may wish to simply add into their descriptions or version notes somewhere that the package depends on another user package, so that once it's been tested, the tester can then also appropriately vote for the dependency, which they've also implicitly tested.
Alternatively, a change to the package interface could be in order so that any vote for a package also chalks up a vote automatically for any dependency that's also a user package - In this case, 10 votes for the original application will also register as 10 votes for the dependency. That's probably not a trivial change to the package interface, though.