Here’s an idea: instead of supporting a React integration, a Mithril, or a Mercury integration, etc, an alternative could be to make infamous/motor/boxer/famin (still need a name! 
) compatible with JSX-syntax so that the JSX compiler would compile in-javascript-HTML into our functional form. We’d then just need to provide a couple simple helpers for each of those libraries (React, Mithril, etc) so that when our component is used, our library takes over that part of the UI tree.
I’m not sure which of the two is simpler and/or better: this idea I just described, or making an actual integration for each library (where integration means using each library to define how our tree is created/destroyed using each library’s life-cycle hooks).
In the first case (the idea in the first paragraph) We need to use life-cycle hooks only for the adapter component, but then the rest of the tree can be handled entirely by our library and we can define our own mechanisms (i.e. our own life-cycle hooks or anything else we see fit for managing our render tree). It might be less work to manage for us, and once each library hands control of their tree to us, then at that point the code-base is shared across all the other libraries (React, Mithril, etc).
In the second case, each library would control our render tree with each of their respective life-cycle hooks as a sort of exo-skeleton wrapped around our render tree. We would have to maintain more code per other library in order to remain compatible with all.
I’m really starting to like the first paragraph’s idea! We just would need to make sure JSX has some way of mixing the underlying function calls between libraries, with some way to define an adapter the specifies how one tree transitions into the other tree when traveling down the apps overall UI structure. I made an issue on GitHub to see if anything like that already exists.