Error binding links in /tmp directory

Description

If I attempt a bind mount where the source is a symbolic link in the /tmp directory, I get an error. This is on a linux system where /tmp is mounted as tmpfs. Bind mounting a symbolic on a regular (btrfs) file system works fine. It doesn't matter if the link points to a file under /tmp or not, only the location of the link itself.

Reproduce

$ docker run --rm -v /tmp/test.link:/test.file alpine cat /test.file
docker: Error response from daemon: error while creating mount source path '/tmp/test.link': mkdir /tmp/test.link: file exists.

For reference:

$ ls -l /tmp/test.link
lrwxrwxrwx. 1 aaron aaron 14 Apr 29 15:00 /tmp/test.link -> /tmp/test.file

Expected behavior

This should cat the file, the way it does when the link is not inside /tmp.

$ docker run --rm -v /home/aaron/test.link:/test.file alpine cat /test.file
tmp test

docker version

Client: Docker Engine - Community
 Version:           23.0.4
 API version:       1.42
 Go version:        go1.19.8
 Git commit:        f480fb1
 Built:             Fri Apr 14 10:35:38 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          23.0.4
  API version:      1.42 (minimum version 1.12)
  Go version:       go1.19.8
  Git commit:       cbce331
  Built:            Fri Apr 14 10:32:40 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.20
  GitCommit:        2806fc1057397dbaeefbea0e4e17bddfbd388f38
 runc:
  Version:          1.1.5
  GitCommit:        v1.1.5-0-gf19387a
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.10.4
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.17.2
    Path:     /usr/libexec/docker/cli-plugins/docker-compose
  scan: Docker Scan (Docker Inc.)
    Version:  v0.23.0
    Path:     /usr/libexec/docker/cli-plugins/docker-scan

Server:
 Containers: 7
  Running: 3
  Paused: 0
  Stopped: 4
 Images: 55
 Server Version: 23.0.4
 Storage Driver: overlay2
  Backing Filesystem: btrfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: nvidia runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 2806fc1057397dbaeefbea0e4e17bddfbd388f38
 runc version: v1.1.5-0-gf19387a
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.2.8-200.fc37.x86_64
 Operating System: Fedora Linux 37 (Workstation Edition)
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 31.2GiB
 Name: guppy1
 ID: b784c941-9686-47fb-ae2a-e9a708ba7cf7
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional Info

No response

Start by reproducing the docker run --rm -v /tmp/test.link:/test.file alpine cat /test.file command on Linux with /tmp mounted as tmpfs, then compare it with the working /home/aaron/test.link case. Trace the Docker CLI mount handling and determine what change would make the /tmp symlink case produce the expected file contents without the file exists error.