I'm sorry but if there was some semblance of unit testing for non-gui stuff in Code::Blocks (and Macros can very easily be unit tested) things like this would be a lot less likely to crop up.
Have to object here. It's not a matter of testing, or of any actual bug.
We have three issues:
1. the same string gets passed to MacrosManger several times during build (not during abbrevations, though). This could be considered a bug (at the very least, it is unnecessary), but it does not matter, because of (2).
2. in addition to that, MacrosManager will keep replacing any variables it can find in a semi-recursive way (there is no "real" recursion as in function calls, but it works in a recursive manner)
3. although I did (2) by accident in the first place, it happens to be the correct way, just like it has to be. Otherwise nested macros like
$($(TARGET_NAME)_OUTPUT_FILE) will not work.
To be able to address the problems, we don't need to test or find a bug. What we need to do is decide whether or not we want to support nested variables like
$($(a)b).
If we can drop that feature (personally, I'll be happy with that), then implementing escaping properly should not be a big issue. However, I don't have any figures on how many people use it, and how important it is.
If you think that unit tests should be done, feel free to start a "test" application.
However, it is my belief that unit tests generally don't make anything better. wxWidgets is the best example for that, they have plenty of unit tests, and plenty of dumb errors that nobody seems to see, nevertheless.