After looking at this again in more detail, more compiler weirdness emerges about how text properties are assigned differently in I6 by the following three syntaxes for assertion in I7:
now the description of the large button is "A red button".
translates into I6 as
BlkValueCopy(GProperty(10, tmp_0,description), TX_L_81);
.
now the large button is-described-as "A red button".
translates into I6 as
tmp_0.p7_description = BlkValueCopy(I7SFRAME, TX_L_81);
.
and (leaving aside the loop code)
.
now every button is-described-as "A red button".
translates into I6 as
x.p7_description = TX_L_81;
The essential difference between the first syntax and the second and third is that the first overwrites the text pointed to by the description property without altering the pointer, whereas the second and third leave the text originally pointed to by the description property unchanged but change the description property pointer to point to a different text- in the second case to a copy made elsewhere of the original text literal “A red button”, in the third case directly to the original text literal itself.
There is a further subtlety in the operation of the second syntax, in that there is a separate copy made for each line of I7 using it, but if the same line is returned to, e.g. in a repeat loop, the same copy is reused, meaning that (like in the third syntax) the description properties of multiple objects referenced in a loop will all end up pointing to the same text in memory- and if this is subsequently overwritten by a change to the description property of any one of those objects by means of the first syntax, the descriptions of all the objects will change in parallel.
What this means in practice is that unless these idiosyncrasies create the effect you’re looking for, you must be careful about mixing up assertions of text property values using the conventional ‘now the (property) of (object) is (text)’ with assertions using verbs derived from ‘To (verb) means the (property) property’. Sticking to one or the other with a given text property type will work fine.
Because of the different way assertions are translated into I6, properties with numerical values don’t have these problems (including enumerated values created with ‘(property) is a kind of value’) -with these you can mix the methods of assertion with impunity, including when asserting them to be equal to variables.
EDIT- PS I haven’t tested this with other kinds of value such as lists or table names, but suspect these might cause problems similar to texts, being represented by block values in I6.
EDIT- V10 has changed things slightly, in that the loop evoked by now every.... now calls BlkValueCopy() e.g.
x.description = BlkValueCopy(I7SFRAME, bc_U191)
but while this refreshes the set of pointers in the relevant description properties each time the loop runs to point to a fresh copy of a text (in this case of bc_U191), it remains the case that each cycle of the loop recycles the same pointer (as described for Syntax 2 above) so the effect remains that all descriptions point to the same copy of text and updating any one of them with now the description of ... is ... will unexpectedly update them all.
It remains the case that exclusively using the allocated verb to update the descriptions, either singly or as a group, will work as expected, as long as this is not mixed with the standard now the (text property) of (object) is (text) syntax.