Maybe we can understand you better if you explain your real need. It prevents x,y problem solutions.
What is your exact issue with exact domain entities and lets see from there. Like @Hellis81 already describes is a good sample of exact scenario and also states ‘give us your situation in details’
MQTT values can be retained.
Tasmota can be restarted immediately after HA restart, so they will be up.
I have a couple of things like a sensor that tells me about daylight level, I force run that on restart so-as not to wait for an update. this can be done for anything critical.
I use these and there are probably other things that can be restarted to force update.
And to be honest about all this „something could have been changed in the meantime“:
How many of you do reset most their Zigbee2MQTT sensor values to „unavailable“ ‘manually’ with an automation after the adding restarted, because someone could have opened a window in the meantime? 
There are a lot integration that handle that quite the opposite to HA itself, leaving us alone with a wild mix of behaviors on restart.
I think the truth is (like so often) somewhere in the middle.
Maybe an per entity override would be nice, so you can decide for single entities to show the old state. E.g. my HA isn’t offline for a long time ever. And I update almost always when the family isn’t at home.
But having to look at wrong states for entities that don’t change often would also put me in a bad mood (like some windows showing ‘unavailable’ for a whole day until the next ‘ping’ because we normally use another one in the same room).
Luckily most sensors are Zigbee and Zwave here and these integrations report the old state to HA after a restart (even that they also can’t know what happened in the meantime)
My Zigbee devices know what happens when HA is down. I guess you are using ZHA?
1 Like
Sorry, „adding“ should have meant „addon“ in the last post.
No, I’m using Z2M.
And in both cases: Restart Z2M and restart whole server: Z2M „guesses“ that nothing changed about e.g. my window sensors.
Ah, using the add-ons. My mosquito and Zigbee2mqtt run independent from HA, so no problems on HA restarts.
1 Like
Also not for me, as it shows the last state from before also after a restart, differently to how HA handles this for other things like discussed here. 
But in fact it should be the same problem / not a problem for you than for me:
Cause a larger difference in states to before / after restart only happens on longer downtimes. Which might be outage of your server for example. This isn’t specific to using HAOS vs separate installed services.
The general problematic „Should you show the last state or unavailable“ after the corresponding service was offline, stays the same.
Other interesting question: What does HA when you shutdown your separate Z2M instance and what happens when it comes back:
And if this behavior is different to what HA does on an own restart for its internal entities (showing unavailable): How is this to be seen as better or worse?