...so I started digging into this on a test machine. On this test setup, the main interface is re0 instead of mce0, and I'm only trying to do re0, re0.3 and re0.l (as vlan 10).
When rc calls netif start, netif discovers interfaces lo0 and re0 (as expected).
When netif starts re0, it finds child_vlans 3 and 10, and starts them.
At this point (childif_create in network.subr), it creates re0.3, calls ifn_start on it, which is able to find the config parameters for re0.3, and so properly sets the ip, and then brings the interface up.
When it gets to 10, it creates re0.10, calls ifn_start on it, but there is no configuration information for this interface, so nothing more is done.
At that point netif is done.
When devd starts, it finds that re0.10 is a new interface which hasn't been configured, so it calls "service netif start re0.10".
This time, netif finds the ifconfig_re0_10_name config option, and before ifn_start, calls ifnet_rename, which renames the re0.10 interface to re0.l. At that point, we get the kernel message that it's been renamed.
Since netif is still running on "re0.10", it calls ifn_start on re0.10.
No configuration for re0.10 is found, so nothing happens. We cycle through to the "Starting Network: re0.10" message, and then the "ifconfig: interface re0.10 does not exist" message comes from the loop that calls ifconfig with no arguments besides the interface name (just to display the settings).
I tried changing the "ifconfig_re0_l" setting to "ifconfig_re0_10", just to see how it would behave. Since the full netif_start is never called on the interface, the childif_create for re0 creates re0.10, then finds a valid configuration for re0.10, and so brings it up. Nothing ever attempts to rename the interface, and re0.10 is left up, with an address, but the wrong name.
Ultimately, either childif_create needs to call the entire netif_start function, or at least ifnet_rename, rather than skipping immediately to ifn_start. In either case, ifn_start should be called with the *new* interface, which does not happen in either spot currently.
The only reason "service netif restart re0.l" works is that, on stop, re0.l is never deleted, so netif can configure it like a normal interface. Even just "service netif restart" works, since re0.l ends up populated into the interfaces list, since it's never brought down with re0.
What ALMOST works as a workaround: commenting out the "ifconfig_re0_10_name" line, and changing the "ifconfig_re0_l" line to 'ifconfig_re0_10="inet 192.168.10.8/24 name re0.l'. In this case, all the interfaces are brought up properly on first boot, since childif_create is able to find ifconfig parameters for re0.10 (of course, when it goes to do the next step, ifconfig re0.10 up, it can't - however, the interface goes up anyway). Unfortunately, at this point, if I call "service netif restart", it doesn't work: in childif_create, ifconfig re0.10 create fails ("re0.10 already exists"), then ifconfig re0.10 inet 192.168.10.8/24 name re0.l fails ("re0.10 does not exist"), then (as before), ifconfig re0.10 up fails for the same reason. This time, re0.l is in the list for netif, so it tries to start it explicitly, but does not find a configuration. We're left with re0.l with no address.
What does work as a workaround: same as above, but ALSO add the line 'ifconfig_re0_l="inet 192.168.10.8/24"', which catches the case of the service restart. This seems incorrect to me, since I'm essentially duplicating a config line, and because of how many things end up erroring in the backend before the right thing happens. Still, this will keep the server from needing manual intervention every time it boots, so that's what I'm going with for now.
I think I may try to file a bug report, mostly to get some eyes on this which actually know how all this stuff plays together in the background - I don't see a straightforward modification to this that wouldn't have potential unintended consequences, and I feel like I'm starting to push into weird kernel stuff regarding renamed interfaces (getting, on two sequential ifconfig commands, errors stating "<if> already exists" and "<if> does not exist", doesn't seem like intended behavior somehow).
EDIT: tracked as bug
PR 258257
