helena
well, I walked through it and didn't see any smoking guns. I was remotely concerned that the camera could get to the player before the last tile timers finished their fade-in (and then the fade-in group is getting deactivated - I though that might lock a tile in a state that prevents it from being destroyed). But I ran a test, and that would not be a problem.
I notice you set the MapArray to mapwidth+1 but the Random and Temp arrays are only mapwidth. Any chance there is a rogue tile in the data being imported?
The only way I could get a tile to fail to fade out was if it did not pass the overlap test at event 92. If the collision map for one of the animations (on a less common tile does not have a point inside the x+16, y+16 spot you are checking, then it will not get removed. So check collision maps, and origin points - I routinely accidentally click somewhere I shouldn't and change an origin (and not notice) , or forget to make one of the animations match all the others...
For debugging purposes, I would zoom the layout scale out so you can see the whole map at the start of the fade out group, and show a live tile count in a debug text box so you know for sure whether the tile count is not getting "less than or equal to 1" to satisfy event 94. Or if maybe some other strange combination of events is happening somewhere else (like somehow disabling the fade out group before it gets finished). The fact that it happens rarely certainly makes it harder to track down - but there always is a logical explanation.