Feature Request: docker tag option to preserve/generate RepoDigests config entry when locally retagging an image to a different registry

The scenario here is that we publish an image to a given registry, teams pull these images and test them, then later on we publish the same exact image to a different registry. When a team pulls the image and tests it they retag it to appear as if it comes from the second registry so the work they do on it doesn't have to be redone when the same image comes from the second registry.

Example:
docker pull registry1.com/repo1:tag1
docker tag registry1.com/repo1:tag1 registry2.com/repo1:tag1
docker rmi registry1.com/repo1:tag1
---- then do stuff with the retagged image like run dockerfiles without having to change the FROM statement ----

When the image is retagged with the destination set in the same registry/repo with a different tag the repodigest is preserved and doing "docker images --digests" shows the old and new tag both having the same digest. When the image is retagged with the destination set in a different registry with the same repo and tag, the repodigest is not preserved and doing "docker images --digests" shows for the digest.

I understand the manifest digest is determined by the registry when you pull it, because this digest can change if different registries use different manifest formats so it makes sense that this does not happen by default. However, we control both registries and preserve the same exact manifest when pushing to one and the other and our partner teams are aware of this precisely so the work they do after retagging the registry1 image can be relied upon as if it came directly from registry2. One partner team is using the repodigests config entry for something, hence we would like a way to have this entry stay populated when we retag.

For full clarity, the use case with what we would want the outputs to look like would be the following (with the proposed --preserve-digest command option):
docker pull registry1.com/repo1:tag1
docker inspect registry1.com/repo1:tag1
{
"Id": "sha256:54321...",
"RepoTags": [
"registry1.com/repo1:tag1"
],
"RepoDigests": [
"registry1.com/repo1@sha256:abcdef..."
],
....
}

docker images --digests
REPOSITORY TAG DIGEST ...
registry1.com/repo1 tag1 sha256:abcdef...

docker tag --preserve-digest registry1.com/repo1:tag1 registry2.com/repo1:tag1
docker inspect registry2.com/repo1:tag1
{
"Id": "sha256:54321...",
"RepoTags": [
"registry1.com/repo1:tag1",
"registry2.com/repo1:tag1"
],
"RepoDigests": [
"registry1.com/repo1@sha256:abcdef...",
"registry2.com/repo1@sha256:abcdef..."
],
....
}

docker images --digests
REPOSITORY TAG DIGEST ...
registry1.com/repo1 tag1 sha256:abcdef...
registry2.com/repo1 tag1 sha256:abcdef...

docker rmi registry1.com/repo1:tag1
docker inspect registry2.com/repo1:tag1
{
"Id": "sha256:54321...",
"RepoTags": [
"registry2.com/repo1:tag1"
],
"RepoDigests": [
"registry2.com/repo1@sha256:abcdef..."
],
....
}

docker images --digests
REPOSITORY TAG DIGEST ...
registry2.com/repo1 tag1 sha256:abcdef...

Thanks!

Start by tracing the docker tag command and how it currently handles RepoDigests when the destination uses a different registry. Define the option's behavior against the pull, inspect, docker images --digests, and docker rmi examples; done means the destination RepoDigest is preserved only when the option is requested and the documented outputs match the proposal.