hope not tied to SystemD

I am perfectly fine with udev. This is not the point of discussion. The point of discussion is *IF* a specification should leverage or not on udev when we are talking about /dev

FHS should define what users and/or developers should expect from the filesystem. If it is not possible, the specification should either:
1) explicitly state that it is out of scope,
or 2) point ti another specification

Both approaches are acceptables.
It has to be point out that udev is an *implementation*, not a *specification*, and leveraging to udev is an mistake because understanding what udev does is possible only reading the source/man page/configuration files which is an activity long and errors prone.

Therefore, the most appropriate course of action would be to leave /dev device management out of scope for this specification, rather than deferring to an implementation like udev.