A fork (not a hard fork) is just depending always on upstream. To be compatible with systemd-udev eudev needs to jump the same, include the same development and function-calls. So eudev is per definition not free from systemd. It never was, it never will be. The same as with elogind: Both have to jump in the same development and support the same functionalities, implement the same additions. Otherwise essential other applications won't work. That's the point with KDE and Gnome. Both ignorant enough not respecting the freedom of choice. And same with most all other desktop-environments

It is NOT free from systemd, it is NOT free to be called as alternative. It is just a helper to simulate something being there. As long as those so-called "alternatives" are used the real problems are not possible to be seen. And one essential problem is that many calls around and in GNU/Linux are going with udev, which is essential part of systemd. There is no alternative implementation, it is just this. Same as with D-Bus and many others. There are "alternatives", but they have to follow the so-called standardized implementations. There is no different choice or other possible solution on that special road. And HyperbolaBSD won't have any "udev". So Hyperbola GNU/Linux-libre does not need it either.

There are surely variants like eudev for example giving the udev-version out and trying to backport functionalities towards existing implementations before udev was integrated into systemd in a whole. This may work for the time being and is some wrapper around. But the longer and newer implementations get the more problematic this is going. Also for Hyperbola with the current ideas within here as they are also partwise a wrapper with libudev-zero, which is a intermediate "library in the middle" for simulating. With our current way forward we will pay a price for sure and this means also especially going away from very centric applications and projects around Gnome and KDE. Those will stop working sooner or later for sure.

To underline: Not udev itself is going to be the problem besides being foremost only onwards GNU/Linux, but the inclusion of udev into systemd is the big elephant in the room. And with its exclusive integration systemd became also even more integral element. It is not just that Linux (with or without GNU) was designed in its roots that way, it was made that way over the course of corporations and companies doing that. And this way of forced adoption got that problems ahead. Exactly this, because maintainers of systemd said so often that nobody is forced to use systemd and now what? We all know that this phrase is just done out of convinience. Would systemd not be that much adopted? Well, working. Would systemd be adopted (which happened)? Well, you can always go for searching alternatives, but we are not responsible for you ending without updates or working tools. Yes, you are. Same as with the removal of 32bit. Is there a thought for people and states simplified not having the money to afford buying newest hardware? We are leaving really people alone with all of this. A minimalistic system, with the point of control by its users and developers together, not just one instance alone.