I think there's a pretty strong argument at this point for this kind of replacing DOM with a response behavior being part of the platform.
I think the first step would be an element that lets you load external content into the page declaratively. There's a spec issue open for this: https://github.com/whatwg/html/issues/2791
When I read your comment I thought "hang on, I remember this discussion from years ago". Looks like the issue dates back to 2017 indeed. I remember this idea being shelved because of concerns around the handling of things like scripts and stylesheets, especially in the context of the idea of HTML imports (which were the next big thing when Google's Web Components advocates harassed other JS frameworks for not being Polymer - until it turned out that HTML imports had to be shelved and Polymer ended up being shelved in favor of the next big thing Google pushed out).
iframe is that kind of element, if they hadn't added the brain dead srcdoc attribute to it to show inline content.
I think some of the proposals I see in that thread are kind of interesting, but to do it properly requires a new MIME type for html fragments, eg. text/html-fragment. This is arguably what htmx should also be using for fragments.
I do kind of like the idea of adding this as an attribute to some existing elements, and they show the inner content by default until the target is loaded. Basically like adding an iframe-like rendering mode to existing elements. Then you could implement htmx's hx-boost behaviour just by setting this mode on the body element and using the htmz trick of links naming the body as a target.
I think the first step would be an element that lets you load external content into the page declaratively. There's a spec issue open for this: https://github.com/whatwg/html/issues/2791
And my custom element implementation of the idea: https://www.npmjs.com/package/html-include-element
Then HTML could support these elements being targets of links.