Ah right the bus ranges have been separated between Linux 6.12 and Linux 6.18 for RK356x SBCs, I forgot about that. They were the same on both PCIe nodes before, which did not cause any issues (AFAIK) but related kernel log entries which looked like an error, but had just “info” severity.
The correct rules are hence these (or your ENV{DEVPATH} solution, which looks fine as well):
cat << '_EOF_' > /etc/udev/rules.d/99-dietpi-nanopir5c.rules
SUBSYSTEM=="net", KERNEL=="eth0", KERNELS=="0002:21:00.0", RUN:="/bin/true"
SUBSYSTEM=="net", KERNEL=="eth1", KERNELS=="0001:11:00.0", NAME="to_eth0", RUN:="/bin/true"
SUBSYSTEM=="net", KERNEL=="to_eth0", RUN="/bin/ip l s dev eth0 name eth1", RUN+="/bin/ip l s dev to_eth0 name eth0", RUN+="/bin/udevadm trigger -c add /sys/class/net/eth0 /sys/class/net/eth1"
_EOF_
The ifupdown-pre.service does nothing but an udevadm settle, i.e. waits for udev to finish all rules. If hence one of the rules (its RUN commands) hang, that service will hang. It is however important to wait for finished udev, otherwise the network interfaces may not exist yet when network targets are reached, or ifup@eth0 may run while the renaming did not happen yet in this case. But ENV{DEVPATH} is unlikely to cause this. If the rule matches, the commands are the same. In /etc/udev/udev.conf, commenting out udev_log=info enables (very) verbose udev logs in journalctl, which can be used to check what udev is doing when, and which command takes how long. But it is a bit tedious to read due to the huge amount of log lines 
.
The interface name swap method of the rules does work well on Orange Pi 5 Plus, but no guarantee that it works as good on RK3568. As said, that chip has general PCIe issues, so possible that the Ethernet adapters are not that ready yet when the renaming shall happen, and then there are the additional Ethernet LED rules, which bring up and down the interface once, to put the LED into correct initial state (else it is lid even without any cable connected and interface down). Those rules are in /etc/modules-load.d/dietpi-eth-leds.conf. Commenting them out (or moving that file elsewhere) could be tested, to see whether this fixes the hanging udev. We should probably remove that anyway (and set the WiFi LED trigger separately), in which case the LEDs fall back to the driver’s own trigger, which means static lid LEDs if a cable is connected, but not blinking on activity.