Overriding dependency versions later in the build chain

Hello,

We have a TeamCity setup where build multiple separate services (every service has a separate build type for this, with a single or multiple Git VCS roots attached; build happens from the main branch of these repositories). These builds are connected together by a composite build, and a rest of the build chain follows to deploy and test the product in various environments (the build chain is linear at this point, with the same build types operating on all services as a monolith).

We have two use cases that we haven't figured out how to achieve with TeamCity:

1. When a build of a specific service is successful, we'd like to mark the revision with a Git tag, and be able to see this tag under dependencies' Changes tab in the rest of the build chain (i.e. instead of referring to a commit in the main branch, the build now becomes a “release candidate” with a specific Git tag). We've tried setting teamcity.build.branch via a service message in that first build, but it doesn't seem to affect what TeamCity displays in the UI.
2. Sometimes, we discover the need to cherry-pick a newer version of a specific service later on in the build chain (e.g., pre-production testing uncovers a bug we need to fix urgently). Instead of re-running the whole build chain with a single version changed, we'd like to override the specific dependency's version/run number and have the Changes tab display the correct information accordingly. Similarly to first point, overriding the dep or reverse.dep VCS version parameters doesn't seem to have an effect.

So far, we haven't found a good solution for these cases in TeamCity, leading to a certain number of work-arounds (most importantly, the Changes tab getting out of sync with real VCS changes when a different version is artifically picked inside a build). Are there ways to achieve this, or should we rethink the design of our pipeline?

Thanks a lot!