update 2.1.3 once update 2.1.4 becomes available

I wouldn't use that policy because what if 2.1.4 includes a fix for an issue in 2.1.3?

My update policy is wait until a month comes put, then update to the newest previous month's version. Patches for bugs go into mainline and are backported so this minimizes bugs in the new features.

Since there is no semantic version locking between versions of different add-ons and such in HA, you may always be at risk of hitting a wall like you describe. Keep backups and rollback, that's about the best you can do.

In the future, they would be smarter to use semver locking so you don't accidentally update something that is incompatible with other versions of things like a package repo, but that's a lot of heavy lifting that will take awhile to sort out.

I wish HA would have LTS versions, I would absolutely run it, like I do on my servers.

Backups are important when dealing with software like this. Don't click "update" unless you can spend the five or ten minutes to restore a backup (or have the hour or two to fix things). Do regularly update, though, because the longer you stay behind, the more difficult it will be to catch up later. I generally YOLO the home assistant updates and hit update whenever there's a prompt.

As for the Zigbee2Mqtt thing, don't update major software releases without checking the change logs. If software decides to go from 1.x to 2.x, something significant probably changed. I wouldn't stick with the old version forever, but i wouldn't update major versions unless I have an hour or so to fix the breaking changes.

With Zigbee, you can configure many devices to connect to each other directly, so even when Home Assistant shits the bed, you can still turn your lights on and off. Not as feature rich as full home automation, but probably the best choice when you share your house with others.

You could go for a staging environment but there's no way to actually test that without having dedicated hardware hooked up to the staging server, so that's probably way too much. Instead, I'd focus on a good backup solution. For instance, making daily backups (or more! Only record the bits that are changed!) if your home assistant disk, using tools like virtual machines and ZFS. Put any databases with important long term storage on a separsre (virtual) machine so you can revert home assistant without data loss. This time your problems may have been caused by a significant update, but next time it could be a random particle taking billions of years to cross half the universe just to hit your RAM in exactly the wrong way and corrupt your entire OS. If you can easily recover from crashes outside of your control, you can reuse that tech to recover from crashes you accidentally caused yourself.

2.1.4 is fixing things in 2.1.3 and when those broken things effect you because you decided to install a known buggy version, then you'll shift the complaint that it shouldn't have let you install the broken one that would have effected you.

Pay attention to the update notes and let the system take backups, that'll cover you 99% of the time.

I had something similar happen with a Node-Red update a few years ago and I stopped allowing automatic updates and started reading the notes and being proactive about my updates and have had zero issues since because I ensure my system is ready for the updates first.

Yeah, I've been dealing with the fallout of doing a firmware upgrade suggested by zwave2js which - I don't know - changed the IDs on every single one of my 60 z-wave devices. I've been going through fixing dashboards, and automations, and scripts. It's been a major PITA. It is, however, the first time a breakage of this magnitude has happened to me in a decade.

It wasn't just that devices changed; some stayed the same but the entity value IDs of their functions changed. It was so random.

I'm going to think twice about doing that, next time.