WackyToaster
OK, I've made some progress with trying to understand these problems.
ParticleBug.c3p. The bug where a particle moving to a negative position < -12,297.21 is because of how negative numbers are stored in binary (the particle falling upwards eventually exceeds the store limit of a float32). There is nothing I can do about this: it's a limit of the engine.
ParticleBug2.c3p. When I made the plugin I hadn't anticipated this behavior. You can create multiple shapes of particles, each shape can be given the same tag so they all associate inside the same particle group. However, if you destroy all of the particles in the group (as in this example) then the next particle creation in that group causes the engine to fail. I don't know why this is (yet) and I'm still looking into it. The work-around (for now) for creating groups in a cycle like this, is to use a variable to set the group tag and increment it after each creation cycle (see linked example).
discrepancy.c3p. This problem was caused by the same fault as above. See the example - by changing the particle group tag then the problem can be avoided.
grouptagmaxcountissues.c3p. This appears to be another feature of the engine: if you try to create single particles totalling more than the max count limit then it causes a crash, but only if you create them in a new group in one game step cycle (tick). I think that it doesn't happen if naming the group "A" because the max count has already been initialised. I'll take a look to see if there's a way of editing the library to fix this (that won't create an overhead).
Here are the adjusted bug examples with the workarounds I mentioned: link