I thought so too but I actually doubt it, because that’s just python string concatenation. So the result is just a string, shouldn’t make any difference. And I did check; it doesn’t make any difference, the string comes into the TDL module in a proper state, having all the information, just like in the trunk.
I suspect right now that this has to do with RELS.LIST perhaps being an unexpected geometry, from the TDL parser point of view… Though that doesn’t make too much sense either, because like I said, I would then expect all the tests to break. Nonetheless, for this test, for this lexical rule, the TDL parser ends up parsing RELS.LIST as a “feature” rather than as a “list”… While in the trunk, it happily parses RELS <! … as a “dlist”. I am debugging but it is rather difficult of course, given the data structure with lots of parentheses.
And I still think that the most likely explanation is that I am not noticing a mistake in the string itself. Like a TDL syntax mistake, such as a missing paren (it has to be something else in this case though).