About Tyxml itself: I think that it addresses a rather different set of issues (ensuring that the DOM is "statically correct" w.r.t. definition of HTML5/SVG).  We haven't identified those issues as being relevant for us, i.e. we have never hit a bug related to breaking such validity constraints, and the lack of static typing does not seem to make refactoring UI code more difficult or fragile; so it's not clear to us that adding more static typing here would help.  If we tried to combine it with our vdom approach, it would probably add some noise, since the vdom type would receive extra type parameters, which would be visible in the interface of all components exposing "view" functions.

Tyxml is not only about type-safety. It's about providing an exhaustive, consistent and convenient HTML5 API for your users.

Tyxml also gives you combinators covering the complete HTML5 surface API. This API will be exactly the same as the various other implementation of Tyxml (textual (Tyxml.Html), dom/react (Tyxml_js), incremental (JST's library), react/shared (in eliom)).
Any user that is familiar with one of those API will be able to pick up the others extremely easily.

Currently, in your API, you implemented 3 elements: div, input, span. You'll have to build all of the others by hand. You don't even have attributes, only the underlying primitives. Tyxml provides a nice API with sum types and correct types for all HTML5 attributes.

Finally, you get a syntax extension that takes the usual HTML syntax and generates the appropriate combinator calls. You don't have to use it, but some users want to. :)

Of course, there is a price to pay, you need to implement Tyxml's Xml_sigs.T. I believe it's not a high price, although your extra type parameter makes this kind of things more delicate...