Ok, RuntimeInstance dumps the vm namespace for a template before parsing it. It does this under the assumption that if you are reparsing the template, it must have changed. If it changed, we shouldn't keep local macros around, as they may no longer exist in the new version. This still seems to me that correct behavior. When rapidly (re)parsing the same template in multiple threads, this means that thread B may dump the namespace newly created and not yet used in rendering by thread A.
This unfortunate event can be avoided by permanently caching templates, or greatly reduced in likelihood by caching them with an infrequent modificationCheckInterval. Though, even there it is possible, i think.
So, here's the choices i've thought of thus far:
1) leave it and add disclaimers about inline macros when templates aren't permanently cached
2) we can flip the bit and risk memory leakage (and potential interference) from stale macros
3) add another config switch to let users choose between #1 and #2
4) synchronize creatively to prevent simultaneous parsing and/or rendering in the same namespace
5) try to find a way to refactor so inline macros are kept with the template, not managed centrally
#5 is more than i can take on right now, and probably won't work for the 1.x branch. maybe in 2.x
#4 would probably both wreck performance and never quite work right
#3 is tiresome, but probably the best current option
#2 would probably only be terrible for people with users creating templates, but could be quite the memory leak for them
#1is arguably acceptable for 1.7, but is not a long-term solution