(Moderator note: with the author's permission, I've moved this post here as it poses only technical questions.)
i read through the rationale in your draft proposal, and it just doesn't feel like the rationale explains the choice of solution.
The first problem is that there's a lot of punctuation here: commas, parentheses, and brackets. This is a pretty superficial problem, and it's probably not a showstopper by itself, but it is something that it'd be nice to avoid, because it does distract a little from the content.
i don't think this counts as a problem. maybe half a problem?
The second problem is that, because we're using array literals for the children, the type-checker is going to require the elements to have a homogeneous type. That's fine for our HTML example, but it's limiting in general, because some trees are more generic and would benefit from propagating the types of the children into the type of the node. For example, SwiftUI uses this for various optimizations within the view hierarchy.
the proposed solution doesn't address this problem. without variadic generics, the elements still need to have homogenous type. if the workaround is this, i don't want it.
The biggest problem, though, is that it's awkward to change the structure of this hierarchy. That's fine if our hierarchy is just the static contents of Moby Dick , but in reality, we're probably generating HTML that should vary significantly based on dynamic information.
the most straightforward answer to this is conditional element inclusion, not function building. it would be a step further from the original compile-time inclusion idea, but you could use it outside of a function building API, so it would benefit the whole language.