The problem here is once more the order of text processing in MediaWiki. MediaWiki strips out <nowiki>-blocks and inserts placeholder strings UNIQ... instead. It would be possible to expand the UNIQ... placeholders (and the MediaWiki parser does that later on anyway, which is why the page displays properly), but I think we cannot find out how the UNIQ... part was generated (i.e. the orignial user input is lost). Various tags are handled in a similar fashion, including HTML comments and <math> blocks.

It would also be hard to have a datatype for un-parsed strings, since MediaWiki parses (and escapes) strings before SMW even looks for annotations. The only option would be to hook into MediaWiki at some earlier stage, creating extra load and possibly breaking template compatibility.

I do not know how to solve that problem. But a simple workaround would be to omit <nowiki> and to use other escapes for wiki markup instead (e.g. by using hex encoding for "["). I agree that Type:Text should probably do something to expand UNIQ... before storing the result (but then how would we get that expanded text back into a wiki page, without having special markup escaped?).

At leat we now catch this case properly and raise a generic error. No more mess in Factbox or elsewhere.

This is causing problems for some work that I'm doing (I'd like to be able to put tag extensions in property values).

What's wrong with just expanding out the strip markers with $wgParser->unstripAll() in the assignment? Is Semantic MediaWiki supposed to store the original wikitext in the database, or the formatted HTML?