Neat, but what would be the intended use case for something like this? I can imagine a scenario where one part of the UI may take extra time to load, so you would defer it to let the other parts load first. Is there another reason I'd want this?
I used similar streaming HTML for my RSS reader. When you import subscriptions it can take a while as each feed is fetched so I use streaming HTML to show the progress of each feed as it is imported. This provides meaningful progress updates to the user.
However previously the limitation was that the content needed to be more or less in order (you could use some CSS tricks but they were limited). Using this trick I would be able to render the full list of pending feeds then insert a result as each finishes being fetched.
In fact it seems that for each slot the last element will be used. So you can even create live-updating pages based on this which is really cool. For example imaging you had a score ticker. You could push an update to that region of the page every time the score changes.
I think this is definitely a niche use case, but it is very nice to support this without JS. Of course in all but the simplest use cases JS may still be the right solution. For example if the connection drops for any reason there is no mechanism for showing the user an error, let alone retrying.
Dealing with loading in a smart way (even small amounts of loading), without extra JS overhead, is the fundamental use case.
For a comparison, basically the entire bajillions of man-hours that have gone into React Server Components [1], and all the many, many complications and footguns inherent in their approach, is trying to solve the same problem.
