I didn't actually quite figure that out. This has to do with constructing a nested parser that doesn't have the same macro context as the outer context, but at least one of the errors is for the sub-parser complaining about an unknown macro, and the second error message may come from the original parser parsing the expression again?

I figured going from infinity instances of 'macro undefined' to two was at least somewhat better. Fixing the two prints I think would require a better understanding of macro parsing (which may be a reason to reject this patch).