> All this escaping stuff is confusing. I am against allowing non-escaped
> output in user messages, so if people need them - they should be able
> to implement solution in template themselves.

If user wants to ability to return non-escaped output back to the client
via a detector I don't think we should be taking that option away from
them - there is a good reason why just about every
web-framework/templating language allows overriding HTML auto-escaping.

However, like those web-frameworks/templating languages the user should
have to explicitly state that they don't want the output to be escaped
and assume the responsibility to "not do unsafe things" that comes with
that ability.

Of all the options mentioned so far I think having a new Exception type
would be the cleanest implementation. Given that Reject is currently the
recommended Exception, I would suggest creating a new RejectRaw that
does not escape the output.

I am happy to put a patch together if there is some agreement around this.