Well, looking at it more closely, I’m not that sure this is a bug, after all 
The fact is, there is a rule that should be written in bold on the wiki page :
A G’MIC pipeline run in a thread should never modify the size of the global image list.
Otherwise, there is a risk that at one particular moment, one thread sees an image list with M images (and M associated names), while another one is removing one (or several images) from the list. Hence the error message you get with the example.
The example is bad, really. In particular, one the thread that is doing this:
-do 300,100 -text[-1] @{com,0}\",\"@{com,1},5,5,13,1,255 -w[-1] -rm[-1] -wait 200 -while 1
It just doesn’t stop creating and removing a temporary image that is put on the list. No surprise that it finally interfere with the other threads.
A probable solution (not tested) would be to isolate this thread in a local environment:
-do str={com,@0}\",\"{com,@1} l[] 300,100 -text[-1] $str,5,5,13,1,255 -w[-1] -rm[-1] endl -wait 200 -while 1
So that the size of the global list is not modified, but only the size of the sub-list associated to the local environment.
EDIT: A “correct” way to write the multi-threaded example at the end of the wiki page:
bug :
(0,0) nm. com
parallel "repeat inf =[com] $>,0 wait 200 done",\
"repeat inf =[com] $>,1 wait 100 done",\
"do str={com,@0}\",\"{com,@1} l[] 300,100 text $str,5,5,13,1,255 w rm endl wait 200 while 1"