debugging GC issues?

[WebFreak001]

we have an issue in D-Scanner / libdparse that with very large 
files memory corruption occurs. After further investigation it 
seems that the contents of a string might have been moved as they 
are being reallocated.

The string is constructed 
[here](https://github.com/dlang-community/libdparse/pull/387/files#diff-073a681f37b7ac58a75cb15be50882a5075a2ebcaa53efc4bd97cffa037ab6ddR155) which calls [this function](https://github.com/dlang-community/libdparse/pull/387/files#diff-a10d3a7875381b5020edcd6e55a5555e4c43c8ab1947b30b41b434ce8fa59117R512) which allocates the string using an appender!string.

When first constructed the string is fine but after lots of 
further processing of other stuff the data the string points at 
suddenly is no longer considered allocated by the GC (maybe moved 
without updating the struct members?) and is reused from other 
stuff (in my case it was std.regex putting ir code in there, as 
shown in a GDB data watchpoint that first write to it)

See 
https://github.com/dlang-community/libdparse/pull/387#issuecomment-863442801

Does this seem like it should be possible if all code was safe? 
(`immutable(char)[]` being moved by GC) or do you see any obvious 
issues in this construct?