For this test I used k3d with the following start options:
k3d cluster create \
"trk" \
--agents 2 \
--port="80:80@loadbalancer" \
--port="443:443@loadbalancer" \
--k3s-arg="--disable=traefik@server:0" \
--image "rancher/k3s:v1.20.15-k3s1-amd64"
Clone and build the CRD PR since its not merged yet, then import the built image into k3d
k3d image import --cluster trk traefik/traefik:latest
kubectl create namespace traefik-v2
kubectl create namespace traefik-v3
kubectl apply -k configs -n traefik-v2
kubectl apply -k configs -n traefik-v3
kubectl apply -f https://raw.githubusercontent.com/traefik/traefik/${version}/docs/content/reference/dynamic-configuration/kubernetes-crd-definition-${version}.yml
kubectl apply -f proxy-v2-and-v3.yaml
kubectl apply -f kubernetes/apps/dashboard-v2.yml -n traefik-v2
kubectl apply -f kubernetes/apps/fallthrough.yml -n traefik-v2
At this point you should be able to access the dashboard of the Treaefik v2 instance while going through Traefik v3. Any application deployed with the old CRD API will be recognized and exposed in Traefik v2 but also acessible from v3 because of the fallthrough rule.
The easies way to validate that is to deploy a new dashboard CRD, this time with the new CRD API so it gets exposed in v3 and gets prioritized
kubectl apply -f kubernetes/apps/dashboard-v3.yml -n traefik-v3
Now when accessing the dashboard you'll be presented with the v3 dashboard. The same principle can be applied for any exposed app, once you deploy the new CRD it will take precedence over any route with the same match on v2.