Fallback could always be to do it the old slow way.
And if some attacker gains access to your system I doubt the first thing they would do is to alter the hash of “config.cached” - the most likely run some cryptoware or simply just “shred -y /*” or something.
@Apachez I wouldn’t even bother with the attack scenario as well (If firewalling / authentication is not properly handled or if passwords are shared, this is the administration responsibility, always). Additionally, I wouldn’t bother about “manual configuration changes” as if you do it, and something wrong happens, this is also your own responsibility, so live with it my friend. 
The point wasn’t that getting attacked is its own problem. It’s that a complete change to the configuration system isn’t simple and its clearly not a fully fleshed out idea yet. There are many unknowns that need to be considered.
What if one wants to copy a config.boot and change just the eth1 IP and dhcp scope? Now they may also have to deal with hash issues on first load.
What do you do when hash doesn’t match? Not load any configuration? Try to load it with incorrect parameters? What if loading fails? What if there’s file corruption that affects the hash?
There are likely many scenarios that haven’t been considered.
Hash is only a failsafe for fast booting, so the system could take shortcuts to reduce the loading time, if no hash is present or if it doesn’t match, it can just default to the existing way. 
Just like that.
If the hash is missing or incorrect it can boot the old slow way and verify each and every line by line.
If hash is correct it knows that all lines have already been verified so it can throw away 99% of the overhead and have the commit and boot done in a few seconds instead of several minutes.
There’s still at least one unknown where the hash in there matches, but the config is not actually correct. If an admin does it to themselves, that’s one thing, but if there’s an external reason for it to of happened then you’re introducing an pretty big unknown factor with no way to guarantee the hash is actually confirming the configuration is legitimate.
Enterprise hardware boot times are routinely 5+ minutes, even with zero configuration.
If you’re really concerned with virtually immediate operational status from boot, maybe Alpine Linux running FRR would be more appropriate for your use case?
I can live with this unknown. No problem, make it optional, so we decide whether to use this function or not. Then its my responsibility, if something goes wrong. I don’t mind signing a paper “hey if this server catches on fire, then its my responsibility”.