The Display Expression conundrum solved… The issue is regardless of whether you precompile the expression to a string (i.e. here, the value of $MyString) or not, in code like a stamp you have to remember that $DisplayExpression is an Action-type attribute i.e. a String that holds one or more complete action expression(s). IOW:
Unwittingly, in both cases, you were doing this:
…and Tinderbox was getting confused. So the correct solutions were:
Note we need two different quote types here. We use single quotes as the overall string enquoting method as the code within uses double quotes. Or, and better (why—see below):
Note in line two the quotes. This is saying make the value of $DisplayExpression the literal text ‘$MyString’ and not the value of that string. The actual value of the $MyString attribute is then read when the Display Expression is used. It’s simpler that all that text makes it sound, once you get the principle.
Why might the second form be better? As the number of students grow, so to the number of Display Expressions being evaluated on the fly. The the combo of the number of notes and the complexity of the Display Expression can slow things down. Unlikely in this instance, but a point to bear in mind if planning to use Display Expressions at scale (e.g. via prototypes). In the second method the Display Expression simple reads a string, no on-the-fly calculation is needed.
Edit: a tip when debugging Display Expression or Hover Expression code set via an action. Look at the code box on the relevant Inspector. If the code looks wrong you’ve probably hit some variant of the above mistake.