How to branch a snapshot dependency graph with reverse parameter injection?

I am having problems creating an aggregate build that schedules separate build chains run with different build parameter reverse injections.  

Lets say I have a two step chain, “Build”, and “Upload”.

•  “Build” takes a parameter “configuration” and “Upload” takes a parameter, “destination”.
• “Upload” depends on “Build”.
   

I then create two aggregate builds, depending on "Upload", with specific parameters

• “BuildReleaseUploadTest”.  It has parameters “reverse.dep.Build.configuration=release” and “reverse.dep.Upload.destination=test”.
• “BuildReleaseUploadPublic”.  It has parameters “reverse.dep.Build.configuration=release” and “reverse.dep.Upload.destination=public”.

I can run these aggregates and the correct thing happens.

But:  Lets say I want to run both aggregates.  Build “release” and upload to “test” and "public".  I create a new aggregate:

• “BuildReleaseUploadTestAndPublic”
  It depends on both “BuildReleaseUploadTest” and “BuildReleaseUploadRelease” aggregate builds.

This is where the system breaks down.  When I run this, it will run both of the dependend aggregate builds, but both of them will depend on a single instance of the ‘Upload’ build.

What I expect:

A “Build runs once in ”Release".  Two “Upload” builds are then run, both depending on the release build, but with different “destination” parameter.

What happens:

A single “Upload” build is built.
Teamcity runs it with conflict parameters:

• conflict.BuildReleaseUploadTest.destination=test
• conflict.BuildReleaseUploadTest.destination=public
   

Discussion

Teamcity notices that there are different parameters being applied to the build through the chain, but instead of forking the build into two actual build based on the differeing parameters, it just notices this and carries on.

The above is a very simple problem.  We could simply duplicate the “Upload” step.  Base it on a template and then instantiate two versions based on the “destination” parameter.  But what if we want not just “Release” Build?  Then we have to also duplicate the “Build” for “Test” and “Release” configuratrion.   And then we need two other cases of the upload.   Very soon the permutations explode and it becomes unmanageable.
 

And while it is possible to ask the operators to trigger two build chains separately, what if the chain is more complex?  What if the final aggregate step I suggestsed isn't the last one, but an intermediate step somewhere along the line?

This is what the chain looks like in the dependency graph (build steps have different names from the above)

I am not able to tell TC that the “Chain Test Process” step needs to be run twice with different arguments.


Is there any clean way to do this, or similar things, using TeamCity's declerative apprach to build chains?