Physics: Change "stuck" behavior

[godotproposer]

I'm trying to create a platformer, but the "worst-case scenario" physics behavior seems unsuitable. Since I don't intend to implement resets, deaths and checkpoints, it threatens to place the game in an unrecoverable, invalid state.

Currently, if placed inside of a collider, a body will exhibit extreme zipping when separating. If it's separated into another collider, separation will fail altogether and Godot's supplied movement functions become unresponsive.

Working around using script seems doable, although there are the following challenges with the API: If a body is enclosed, PhysicsBody2D.move_and_collide only reports the body enclosing it. Collision exceptions don't seem to help, since they would apply to an entire TileMap rather than the particular shape involved. move_and_collide can be foregone in favor of manual querying, but this undermines the use of a physics engine. Meanwhile, I can't imagine a project where the current default behavior is desirable, although I understand it isn't meant to be encountered. I created a proposal for these reasons.

Ideal general case behavior would see that bodies contact colliders as usual, but ignore them while inside. In the case where a body is set to separate from one collider and into another, it would fail to separate and thus enter the former collider, then ignore it.

I'm not sure how or if this can be achieved from the engine side, particularly while maintaining performance. Seemingly, it can be safely remedied somewhat by ignoring colliders which completely enclose a given body. Is it possible to reuse the behavior of PhysicsDirectSpaceState2D.cast_motion? Is it performant to allow one-way collision shapes to be used by bodies owning them?

Does anyone else want to see this change, and is it reasonably possible to implement?

[godotproposer]

While playing around with solutions, I learned that body_test_motion does not reliably report the first collision it solved. This doesn't seem like intended behavior to me, since it undermines the designated "test" use case.