1. The best way to avoid creating an explosion of states is [Locality of Behavior]. Elements should avoid targeting other elements that are not inside them, especially those written in different templates. Sometimes this is unavoidable (i.e. updating a site-wide shopping cart). If htmx is adopted widely and those state explosions become an issue (I'm not aware of it happening so far), maybe a "redux for htmx" will be invented.
2. "Classic HTTP and HTML are all about serving static files," I'm not sure about that. In my opinion, dynamically generated responses are a core part of HTTP. All HTML and all the htmx attributes are sent by the server, so we're only keeping the server in sync with itself. I get what you mean though. Going back to the shopping cart example, the code that adds an item to the cart needs to remember that the cart total is displayed in the nav bar and include that fragment. A server mechanism could possibly be created that tracks these dependencies, but again, it's not been an issue yet.
1. The approach is about grafting pieces of HTML inside a htmx-enabled HTML document. These pieces may also contain arbitrary htmx. This may lead to an explosion of possible states. What approaches and tools are offered to manage this explosion, and prevent states that don't make sense? (In the SPA world, things like React and Svelte do that.)
2. The approach forms an ever-changing HTML document. Most often you want such a document to match some server-controlled state. What approaches are suggested to make sure things are in sync? (Say, React can just completely re-render the logical state, only updating parts on the screen which need a visual update.) Classic HTTP and HTML are all about serving static files, even.when following links (GETs should be idempotent); this approach has no such limitations / guarantees.