Not-so-predictable device names

From time to time I have to rewrite my configuration to adapt to new device names. The most recent example is my OVH “kimsufi” dedicated server whose main ethernet interface changed from enp1s0 to eno0 when upgrading (and rebooting) to a new stable nixos release. I also experienced a lot of churn for my external monitor plugged in my docking station. Pick any from DP1, DP-1, DP-1-1 or even once DP-3 after upgrades (over the past six years).

Can someone explain me or provide good references about these issues and the expectations one is entitled to have on device names ?
What are the best practice to work around name changes ?
Is there any way to anticipate these changes before updates ?
Could it be related to changes at OVH ?

External monitor name changes are annoying, but interface names are even more so, which got me annoyed enough to seek your advice :-).

As far as I know the udev sub-system looks at the device serial / mac addresses and builds a “predictable” name based on it. The connection sequence might also affect the naming.

EDIT: it’s also entirely possible that udev have changed their naming rules between version, because reasons.

What happens if you reboot your VM again, do you get a stable mac address?

/cc @flokli the god of systemd and udev rules.

For the network interface, what worries me is that both eno0 and enp1s0 are “predictable” names as per freedesktop specification. Reading the document, there seems to be a precedence for enoX names. My only guess is that the BIOS started providing info avout the interface that it did not provide before. Or possibly linux added a better support for that bios. Just wild guesses here with no way of checking.

As for the display names, the only hints I have is that they are defined by the driver, so changing driver versions might cause the issue. But at the same time I ony use the intel driver. Perhaps there are different intel-compatible drivers fighting for monitor control ?