An alternative would be to have the RootLoggerService only remove the bootstrap handlers once it has been notified that the non-bootstrap handlers have ben added. This would result in duplicate log msgs going to the bootstrap log during the period the bootstrap handlers are being removed, but it should be simple and the duplicates not a problem relative to losing messages.
anecdotally, this could be related to the reseting of the logger priorities as the switch between the logging.properties and standalone.xml configurations happens because even when I comment out the clearing of the boot.log handlers in the RootLoggerService, it still seems like I fail to see some of the messages from the NetworkInterfaceService. I'm not sure the levels were configured consistently everytime I appeared to see this which is why it is just anecdotal at this point.
The approach I'd really like to use is to persist log configuration between boots (via serialization or something). This way the boot logger config is only used the first time you boot. Then subsequent boots would just apply the delta of the old config to the new config (which would normally be 0) during a regular boot. This way the server boots up with a regular log configuration.
Granted this would be a bit of a pain to implement since the LogManager currently does not have the notion of a persistent configuration, and the diff logic won't be trivial. That's why I have put it off.