htmx content swapping and the missing inline script evaluation boundary

htmx swaps server-returned HTML fragments into the page but deliberately does not evaluate inline script elements contained in those responses. This design choice keeps swaps predictable, yet it leaves applications that rely on response-embedded JavaScript without a supported execution path. While htmx.process() initializes hx-* attributes on new nodes, it activates only htmx behavior and does not run arbitrary JavaScript embedded in the swapped markup. The same no-execution rule applies to out-of-bound swaps via hx-swap-oob and to outerHTML replacements, and htmx provides no built-in swap option that enables script evaluation.

Applications needing post-swap logic must instead use hx-on attributes, the htmx:afterSwap event, or server HX-Trigger headers. However, the recommended integration surface has evolved across htmx versions, so the exact hook should be matched to the deployed version. Morphing or third-party swap extensions may also re-parse content differently, introducing uncertainty about script behavior under non-default swap strategies.

Given this constraint, what is the supported boundary for initializing response-embedded scripts under htmx's default swap policy? Does the no-execution behavior remain identical across htmx 1.x and 2.x when using morphing swaps? Which event or attribute provides the most version-stable hook for post-swap initialization when inline scripts are blocked?