Really great insight here with this comment, and that is actually exactly what we’re doing. Our standard CSS stack is based on cssnext, which is essentially babel-es6 for css. Our html stack will be as similar as possible as well, although we are still going with a whitespace-significant parser based on very logical reasons. We do the same for css with sugarss. However, with either one, it’s easy to drop the parser without losing any of the actual features for anyone who prefers the extra syntax, unlike stylus/jade.
Most of the differences from standards are within html, as we use `include`, `extend/block` layouts, loops and conditionals, and handlebars-style templates. However, I don’t foresee most of these updates coming to html as a standard, as they are really compile-time optimizations. It doesn’t really make sense to have an include or layout happen at runtime, just slower for no reason.