The bind9 script I created in /etc/resolvconf/update.d executed systemctl reload named near the end (if systemd is active, which it is for me). Adding set -x to the script showed that this was where the process of bringing up the interfaces hung up.
named is obviously not active when the network is coming up; I thought it would just fail. But, probably because named.service says After=network.service (network, not networking, but I assume they are related), it blocks. The solution was to test first: systemctl -q is-active named.service && systemctl reload named > /dev/null 2>&1 || : The stuff after the reload command was there all along. Tracing this back the chain, because the script blocks the resolvconf -a invocation in /etc/network/if-up.d/000resolvconf, that was the last script showing on my earlier posts. resolvconf -a is only invoked if there was some dns information in the interface stanza, which is why removing dns- lines from ethlan allowed the network to come up, and why bringing up ethworld automatically failed. Now everything just works. Thanks again to everyone. There are probably some general lessons, though I'm not sure what they are. Clearly the systemd semantics tripped me up; it's kind of an odd beast. I understand one of its major goals was to allow startup to proceed in parallel, which is pretty asynchronous. But it has to assure that certain things happen in a certain order, which results in some things being synchronous and blocking. I'm surprised that a tool intended for use from the command line (systemctl) is blocking. Ross