I think it could be possible...
First, parse the content of "htmlText" attribute using custom XML rule and either defining own context or using one of the pre-defined ones (e.g. Paragraph), and pass the context to HTML embedded content processor...
Then setup the HTML embedded content processor to convert the entities, so that it actually gets proper HTML code.

Or maybe the entities conversion needs to occur already in the XML parser? This is something what always makes me perplexed and I always have to just TRY because it gets too complicated ;-)
But you get the idea...

Shouldn't this work? Or am I missing something?

In any case, such terribly constructed XML is simply a crime... :-\
Why on earth did the creator not put the HTML in the TEXT of the "TemplateText" element?!?! Simple and straightforward...

Of course, creating a pre- and post-processing script which will put the HTML in the TEXT of the element for the Studio processing purposes and then puts it back to the illogical attribute location would do as well...

Evzen Polenka said:

I think it could be possible...
First, parse the content of "htmlText" attribute using custom XML rule and either defining own context or using one of the pre-defined ones (e.g. Paragraph), and pass the context to HTML embedded content processor...
Then setup the HTML embedded content processor to convert the entities, so that it actually gets proper HTML code.

This is not possible Evzen because you can't set context on an attribute rule.

You can, but you need to use the XPath option, not the Attribute one.
I'm not sure why exactly is the behavior inconsistent across the options, though...

Actually it's rather something like "anything that a piece of software is unable to do, but logically should be, e.g. by the nature of the existing settings or other logic implied by the usual usage of existing features".

Users don't care if the problem si caused e.g. by a typo or wrong condition in code (i.e. a real bug by your definition) or simply by "oh, the author has not thought about that possibility" (i.e. bad design or simply limited imagination/knowledge).
So from this simple, transparent and common-sensical perspective is the inability to parse HTML from attribute content clearly "a bug"... simply because there are no technical reasons why it should not work, there is no clear clue suggesting (or documentation saying) that it should not work... so users logically expect it to work.

An "enhancement" would be e.g. implementing full embedded content processing to Excel parser. Such functionality is currently not there at all (the existing regex processing is kind of part of the Excel parser, it does not use the generic embedded content processors), so yes, implementing this is an enhancement.
But once it's implemented, it will be expected to work on ANY content which the Excel parser is able to extract (or, if there would be any technical limitations, or if only partial functionality will be implemented, it will be expected to be clearly documented). Users are not interested in excuses like "the developer never intended (read: has not though of) to parse HTML from an ActiveX control caption".

The point i sthat we are not talking about 20 EUR shareware produced by someone in his spare time, we are talking about 2k+ EUR software produced by "industry leader". So I guess it's not that much that users paying so much money expect a "logically implied" functionality.