htmx 4.0.0 has been released

I can provide a comment from my own experience, having used HTMX for some years while also having spent many years using React.

Target drift is indeed a problem that can occur. HTMX is not compiled so there are no automated checks. Tests can go a long way to cover this issue but you're still at the mercy of discipline and exhaustiveness.

However, there are aspects of how HTMX is meant to be used that should further clarify your question.

Targeting by id is not the only way to target elements. In the context of swapping DOM elements that are close to the trigger, I'd reach for other selectors like find, closest, this, etc than an id. Nonetheless, the elements behind these selectors can also change so you still have target drift.

HTMX argues for an implementation designed around locality of behaviour, meaning you'd implement an interaction such that you can see right away how things work out. Yet, this is somewhat contingent on the affordances that your server has for generating and returning markup.

For things that need updating beyond that locality, and disregarding out-of-band-swaps (which are bound to target drift too), I've turned to using custom events or response headers to handle cascading effects.

Obviously, this is way different to the reactivity model that React and others use. HTMX is not that and you'll be disappointed if that's your expectation. I like HTMX for certain projects and use reactive libraries instead where it makes sense. These are not mutually exclusive either; you can delegate interactions/elements that require more reactivity to a reactive library and communicate over events.

That being said, my experience working with developers who only know React or the reactive model is that they'll find it difficult and counter intuitive to use HTMX, and even more so to combine it surgically with a reactive library / plain Javascript where necessary. In a project in which I participated Vue was added progressively until we ended up moving everything over to it when requirements for reactivity where such that it made sense to do so. The rest of the team was overjoyed when HTMX was removed, though HTMX did a great job to carry the project up for over a year while the product found product/market fit and now had enough traction to justify growing the team.

I mean, as someone who uses htmx, three parts to that answer:

1. I don't use htmx for massive sprawling interactive apps. It's not a good fit for that. So I don't know this has ever actually come up.
2. But I also don't really use IDs unless I'm replacing several thing at once. You can always just target this or things like closest .classNameHere and equivalents, in which case this doesn't apply.
3. And to the extent that it would apply, in any large-enough code base, I almost always have linters to prevent this kind of thing for CSS reasons (at least if I'm not using something like BEM or SMACCS or whatever the hotness is right now).

tl;dr: if you're doing something big enough where this would actually suddenly be A Thing, I personally would really say it's time to look at Svelte or React (or maybe Unpoly if you're really set on a mostly-static approach). I think htmx is great at its niche, which is basically web sites with interactive bits. I don't think htmx is great for complex interactive apps, and IMVHO you're gonna have a bad time trying to shoehorn it into that world.