As a general rule of thumb if you are disabling / enabling collisions you should do it via the call_deferred method, as then it will be done at the end of the current frame.
All of my projects so far have used some sort of pooling of objects and you need to do that if you are turning off collisions or the monitorable / monitoring states.
I’m surprised it hasn’t popped up with a warning telling you, you should do that.
I have encountered a similar problem, using an object pool and disabling collision is not enough, the collision data needs to be properly reset. I am trying every solution I can find, Default to delete/queue_free and instantiate, which are not in actuality performant implementations for spawning large numbers of collision processing objects in games and managing performant behavior at runtime.
Object pools are critical for games that deal with 1000s of active colliding objects.
That said, I think that a more elegant solution does not exist yet.
Within the engine’s GD script set of tools, re-instancing is unlikely to save time or horsepower, nor achieve the runtime performance objective.
The set_deferred(“disabled”, true) / .disabled = true only disables the collider from interacting while disabled, but does not clear out latent/bugged collision processing nor resolve this bug.
So, critically needed behavior, a method for clearing collision processing that is “cached” or resetting it completely without re-instancing.
When objects in pools collide with objects in pools, this problem becomes apparent, and it doesn’t always happen consistently.
So it sounds like my Area2D objects that are detecting collision likely have similar behavior, but perhaps harder to observe?
Is this the type of thing that should be put into git as a request/bug report? I haven’t done that before. I suppose I should put together some sort of minimal code example?