> The syntactic mistake of XSLT was writing it in XML, XPath was a redeeming feature. Imagine if XPath was also written in XML...

Yes, I didn't mean to imply that XPath itself is bad (although it also has to handle XML quirks like element/attribute/text, etc.).

Rather that the reason to write XSLT as XML in the first place is that it's machine readable, we can mix and match elements from different vocabularies, etc. yet most of the heavy lifting ends up as opaque string attributes :(

PS: I've done a few projects which make heavy use of jq; it's really nice, but as you say it's more of a pipeline.

XQuery was halfway between XSLT and XPath in expressiveness - functions, loops, queries with joins etc, but no pattern matching. If it only had the latter, it'd be perfect.

I quite liked SXML + SXSLT back in the day (scheme syntax)

It is more concise. Similarly, I was a fan of using attributes instead of text elements (with their unnecessary close tags), but eventually was won over by neatness. e.g. translating an eg from https://www.gnu.org/software/guile/manual/html_node/SXML.htm...

  (parrot (@ (type "African Grey")) (name "Alfie")) 

  <parrot>
    <type>African Grey</type>
    <name>Alfie</name>
  </parrot> 

It's more the one-variable-per-line pretty-printing than the syntax as such, but still.