How to avoid redundant triggering of builds

Hi,

let's say we have a TC project with two build configuration A and B where B depends on A. (In our particular case, A and B would be modules of a Maven project, but this probably won't matter for the purpose of this discussion.) Both A and B have checkin triggering enabled. Everything works as expected for checkins that only touch files in either A or B.
But in case of a checkin that touches files in both A and B, B will be built twice - once due to the checkin trigger, and once due to the dependency on A! This is clearly not what we want - a checkin should trigger each build configuration at most once, obeying the partial order implied by dependencies between build configurations. Since the changes to A and B are often related (e.g. A could be a library's API and B its implementation), what we typically see is that B starts before A has finished (triggered by checkin), turns red (false alarm!), and only turns green again after it has run for a second time (this time triggered by the dependency on A).
Now imagine a project with 30 developers, 100 build configurations, and 20 build agents, and you can probably feel our pain. What happens is that developers don't trust the build server anymore ("Build failed? Thanks, I already know that build results are rubbish!"), which derails our efforts to establish a continuous integration process. (We also have lots of problems with ClearCase integration, but that's an entirely different story.)
Is there anyone out there with similar problems? Any ideas how to avoid multiple runs of the same build configuration? Have we overlooked an existing TC feature, or have we found a missing one? We are currently using TC 3.1.2. (Please don't question the number of build configurations - basically every build configuration creates one OSGi bundle, and we have good reasons for dividing our application into that many bundles.)

Cheers,
Peter