Carl, this would be my analysis. Short on time now, so short explanation Let me define some symbol markers that I can insert in the text, to show various things. these symbols are not actually inserted, they are added to the display just to show the various points indicated. as defined by the buffer that scanning is occurring in, and what is being scanned. First example, various phases (1) [<SV01,BF x>]<PV01><EX># (2) <SV01,BF x>[<PV01>]<EX># (3) 01= [BF xx]# Second example, various phases (1) [<SV01,BF SV02,xx> <GT02>>]<PV01><EX># (2) <SV01,BF <SV02,xx><GT02>>[<PV01>]<EX># (3) 01= [BF ]<SV02,xx> <GT02># that the # has moved, we have a new count based end point, because we are executing the scan in the 01 buffer (4) 01= BF [<SV02,xx>]<GT02># (5) 01= BF <SV02,xx>[<GT02>]# So we get into trouble when ']' and '#' are in the same place, AND we are trying to find a match, because the "find a match" routine terminates 1 count too early, relative the "#" indicated scan limit. So that last scan can't find a matching ">" for the GT verb, and responds by directing the whole verb phase into the junk pile (the screen where the cursor is). So that explains why you see the <GT02> on screen, rather than the <GT02> function being executed. But the point is, you always have to think of where what is being scanned resides, which in turn keeps changing the count defined end point. So, I gotta go now, and will post this. But I hope this illustrates how I am analyzing what is going on. I still have problems with my own explanation, but I think this illustrates how we are analyzing the problem differently. Wally