I still think you're trying to prematurely optimize against your very first impression of seeing a new syntax for a familiar data structure. I've actually written several thousand lines of Elm code for a real internal tool at work, and elmx feels like it just complicates the view code with virtually no benefit. I think it's solving a problem that doesn't exist -- and not at zero cost.
The result won't be understood by elm-format. Compiler errors will exist at the level of Elm, not elmx. It's something extra that has to be learned by any other developer trying to work on the code -- and they'll still have to understand the pure Elm code that the elmx compiles to as well. Plus it has limitations like not being able to nest code interpolations.
This is getting more heated than I care for, so I'm going to bow out. As for your last sentence, just read the README for elmx:
> Non-recursive interpolation: currently Elm code interpolated between { and } is not recursive (i.e. is a regular grammar not a CFG). This means that you cannot include curly brackets inside curly brackets.
This is of course just a limitation of the implementation, not the idea.
The result won't be understood by elm-format. Compiler errors will exist at the level of Elm, not elmx. It's something extra that has to be learned by any other developer trying to work on the code -- and they'll still have to understand the pure Elm code that the elmx compiles to as well. Plus it has limitations like not being able to nest code interpolations.