I may be firing blind shots, I thought about the new dependecy/optional dependency service structure and something may be miss aligned between optional and mandatory, but looking through the code I can't locate where this may be. So I decided to play and see how much the system can take before it explodes.
What if you enable the devices-zfs service in the current tree, in my setup it is root (I did not start it, just enable it). Then I run 66-update, everything went fine, then disabled it, run 66-update again. Then I looked at my trees and see this:
Name : root
Initialized : yes
Enabled : yes
Starts after : None
Current : yes
Allowed : root
Symlinks : svc->source db->source
Contents : /
├─(0,Enabled,oneshot) mount-proc
├─(0,Enabled,oneshot) mount-sys
├─(943,Enabled,classic) ntpd-log
├─(944,Enabled,classic) ntpd
├─(0,Enabled,oneshot) mount-dev
├─(949,Enabled,classic) dhcpcd-log
├─(946,Enabled,classic) tty@ tty2
├─(948,Enabled,classic) tty@ tty1
└─(950,Enabled,classic) dhcpcd
No mount-sys mount-proc and mount-dev are there. This means they were dependent services for zfs and since they were run by boot already they were there.
So then I decided to look at my /run/.....0/current (last boot was after the update and recreation of trees. Except for root stuff seem to have run before boot (higher up on the log) and some clock misalignment issue on mounting root (time in the future) I didn't see anything weird, no failures or warnings.
So mount-proc is needed by mount-sys which is needed by mount-dev which is needed by devices-zfs
Removing/disabling these manually from root didn't affect their status in boot tree.
Should the 66-disable remove dependencies as well?
After this playing around 66-update worked fine and so did 66-intree