I don't fully understand XSLT, but I've been building something which I believe solves a similar problem (albeit JSON-LD and Javascript). The general XML ecosystem of solutions have always looked really complex to me. You need to understand a lot more types/elements than I think is reasonable for people to author with but they are from before my time. I took a look at XForms 2 and it had its own way of defining functions which on top of the other XML quirks has security concerns.
Oh I can't say I like XML and XSLT for the syntax or (lack of) terseness. I appreciate how it handles templating via selectors, logical operations, and runs as a first party templating engine in the DOM without depending on the JS runtime.
I once built a full RSS reader in XSLT. I had to proxy requests to avoid CORs, but it was all based on an XSLT template for OPMLs that would fetch each feed, parse them, chuck the description into HTML including CData parsing, and combine all feeds to sort by date.
It was far from a perfect setup, partly due to browsers having been decades out of date with XSLT, but it gully leveraged browser caching for feeds. Caching in RSS readers is usually really bad from ignoring caching all together and polling frequently to misusing cache mechanisms and causing weird behavior for feed hosts. Letting a browser handle it to spec was great.
If you feel like it, tell me what you think of this. It is just surface level to what I'm working on. The starter project I'm making with it supports screen readers with rich webapp experiences and nojs w3m. But it is a fully Javascript SSR framework.
https://codeberg.org/occultist/octiron#readme