On days like this, I wonder what the heck the authors think - changing their software again and again in incompatible ways. Case in point this time: u/dev (or just udev, as you like).
If it would just be some random tool, tiny utility or whatever, I could not care less, but with tightly coupled pieces, wired into the system boot, low-level device management and the Linux kernel in many ways, I really have my problems with breaking existing installations due incompatible changes.
In the past, already, they renamed the system init programs, such as udevstart to udevtrigger as well as the format and keywords of the configuration files (rules) changed multiple times.
And now, with hundreds of thousand deployed Linux systems in the wild, someone decides “well, we do not like this multiple single tools anymore” and refactored the code to some combined “udevadm” in udev-121.
And we (the people using Linux, the “Linux” vendors, system integrators, and other individual users) can go update the init and system start-up scripts just for the fun of it.
Sure, one can argue the vendor should care and just get it right. But still: Multiple vendors now have to adapt multiple distributions (and embedded systems) and probably many many users will run into problems during updates of single packages to a new major release of their distribution of choice.
A +1 vote from me for less incompatible, random changes. Would saves coders and system admins a great deal of time.