FWIW; we were discussing this Yesterday, and considered that this approach was less ambiguous than treating ServerAddress as a wildcard; some blurbs of the discussion;

• Using ServerAddress == "" as a wildcard can be a potential footgun; there's many place where we consider "no registry means default registry (Docker Hub)"
• For the existing functionality (docker push always pushing a single image), ambiguity is limited, but with work in progress on the containerd integration, it's possible that docker push may support multiple images in future (see Suggestion: Add source image option to docker push #38880), in which case things become more ambiguous.
• We also discussed putting the logic of this PR in the API (if we receive credentials without a ServerAddress, then fill in the address on the first possible occasion), however this would (likely / potentially) break registry mirrors.
• We should (in a follow-up) add proper documentation for the ServerAddress field, and describe what it's used for (and where). Part of the ambiguity is due to (IIRC) the same field being used on the client-side and daemon side, but for slightly different purposes.
• Long term, we want to look at adopting an authentication flow similar to BuildKit (which uses GRPC to request authentication from the client); [discuss] client auth protocol for push/pull #38591

@rumpl @laurazard PTAL

I think we should be ok merging it. It’s master / v25 and containerd, so if there’s issues we overlooked, we can still fix those later, so I moved this out of draft