ls /run/udev/tmp-rules* && { sleep 5; /lib/udev/udev-finish; } &

is missing in

That part of /etc/init.d/eudev now looks like this:

# wait for the udevd childs to finish
    log_action_begin_msg "Waiting for /dev to be fully populated"
    if udevadm settle; then
	log_action_end_msg 0
    else
	log_action_end_msg 0 'timeout'
    fi
    ls /run/udev/tmp-rules* && { sleep 5; /lib/udev/udev-finish; } &
    ;;

    stop)

It is the job of /lib/udev/udev-finish to copy temporary rules in /run/udev/ (which don't survive reboot because they exist in RAM) to the root filesystem once filesystem is writable, but nothing seems to ever run this script (I inserted a line in udev-finish that creates a dummy file, but the dummy file never shows up under any circumstances).

So I think I found a bug: Nothing ever triggers /lib/udev/udev-finish, therefore temporary rules in RAM never get transferred to the filesystem, therefore /run/udev/tmp-rules--70-persistent-net.rules gets generated anew at every boot but /etc/udev/rules.d/70-persistent-net.rules never sees the light of day.

Maybe the timing of things at boot is such that eudev is trying to commit the naming rules to filesystem before the filesystem can be written to?

Those "specialized conditions" I mentioned are various reasons to avoid renaming, and they don't make renaming happen.

Note that net.ifnames=0, net.ifnames=1 and net.ifnames unassigned provide three different ways of hotplug handling of network device adapter naming, with a nice handful of rules files involved. Then there are also at least 2 other rules files involved in the enabling (or configuration) of network interfaces, and those of course depend on the name assignments, especially if there's a renaming involved.

Don't ask me why

IF the hotplug event is due to the (possibly faked) addition of a net device adapter, and the NAME attribute has not been set for it, and the environment does not contain an net.ifnames variable with value 1, and the initial kernel name pattern is one of some few (including eth* and wlan*), and some few more specialized conditions,
THEN make up a name for the device adapter, and run /lib/udev/write_net_rules to generate /etc/udev/rules.d/70-persistent-net.rules.

FWIW - on the system that had the 70-persistent-net.rules file that I removed, I added a usb wireless interface.

Addition of new device adapter -      check
NAME attribute not set -                  check
No net.ifnames variable -                 check
Kernel name wlan1 -                        check
Specialized conditions -                   ?????

When I plug in the usb wireless dongle, I get a message saying that wlx<hwaddr> was renamed from wlan1.
No 70-persistent-net.rules gets generated. Same if I boot with the dongle plugged in.

So who is renaming wlan1? What are those specialized conditions that were mentioned?

Afaict the idea is, that any subsequent addition event for the same net device adapter will process 70-persistent-net.rules first, and that will set NAME for the adapter, and thereby disarm 75-persistent-net-generator.rules.

This seems sensible, but the fact is that my 70-persistent-net.rules is absent, so it cannot be responsible for setting NAME for the adapter or for disarming 75-persistent-net-generator.rules. Something is disarming the generator.rules, the question is what that something is.

Afaict the idea is, that any subsequent addition event for the same net device adapter will process 70-persistent-net.rules first, and that will set NAME for the adapter, and thereby disarm 75-persistent-net-generator.rules. It's all at a deplorable level and style of programming, but I'm sure someone is proud of it.

One thing is that the  logic ignores other possibilities of setting NAME before 75-persistent-net-generator.rules. I have a vague memory of various random "solutions" to adapter naming that end up setting NAME early, and thus also disarm the generation of 70-persistent-net.rules, but without them being grounded in their logic. The result is more untouchable udev rules mess, which is good for nothing but clocking consulting time.

This is a complete mystery to me at this point.

I don't know where that file came from. This system started out in June as a debootstrap install, then added openbox (without dbus). The one that doesn't have that file started out in April as a netinstall with standard system utilities only, then added parts of xfce. Neither were upgrades from jessie, so it can't be a leftover.

Ralph: /lib/udev/rules.d/75-persistent-net-generator.rules exists on all my machines, full of nice-looking code. Neither now nor in the past did any of these machines set the net.ifnames kernel boot parameter.

It's generated by udevd via /lib/udev/rules.d/75-persistent-net-generator.rules when net.ifnames!=1.

Huh. Other than when net.ifnames=1, when else would it not be generated? I have two ascii installs on the same computer; one has 70-persistent-net.rules and the other does not. Interfaces get the old names on both.