So after being preoccupied for a while, I decided to try and tackle this issue again.
I don't think that this problem is a syntax issue. However, I did notice a few logic based issues with how you are designing the platform game in the first place. The best method would be to only use gravity when it matters. In other words, make your game state based, and only apply gravity when you entity is falling or jumping.
While I see reason why you would do this, I don't see how this fixes the problem. I think it would just add complexity to keep track of the "falling" state. It needs to set when the player jumps, is knocked up by an explosion or other external forces or walks off an edge. The latter being the most cumbersome to detect. But the biggest collision issue I have is not directly related to the player walking on the ground, but definately occurs when falling, so applying gravity based on state does not help too much.
The piston problem is a little harder though because it depends on the timing of how you react to entities using AABB. What I usually do is base all collisions on the moving entity that matters the most (the player character), and give everything else a lower priority (moving platforms). The collisions that matter to me the most are ones that come from the floor, so if any entity pushes up on my character from the bottom, I prioritize that in my AABB before all other collisions.
Right now, the pistons are not even moving in real-time, they only jump to a pre-defined position at some phase of the game and push anything colliding upwards (which is handled separately as soon as the new extension is set).
So technically the player is the only moving entity colliding with static geometry.
Mario (cut & paste in IDE)
There are no moving platforms, but an AABB system has to be robust and have multiple checking points (left and right bottom corner) to be able to check for moving entity collisions. Having a state based gravity system will give you better control of when to check for these collisions.Removing gravity except when you are falling is a very good first step, as it'll be easier to check for piston collisions.
Sorry, I do not understand that part. What about the collision when I am
actually falling? The problem that I visualized in my original post still applies, and this is what gives me the biggest headache right now: The player falls down on the floor and their new position is closer to a horizontal edge than the top of the piston.
I could completely leave out dynamic pistons or a grid of boxes and would still run into the same issue. Even if it is only one geometry box that is collided with - falling into it from the top while being close to its side pushes me out horizontally.
I also cannot just make the resolver always push upwards since that would just allow everyone to teleport up arbitrary walls by bumping into them.
The corner of boxes colliding is a worst case scenario for using a penetration depth based collision response system. If you want this case to work I recommend you do use a system that determines the actual faces of the boxes that collided and at what time so you can order your collisions correctly. The bottom of your player box and the top of the piston box will be the first faces to collide) Use swept AABB collision tests to do this.
I wanted to avoid swept collision systems because I cannot understand the math behind it as soon as more complex shapes than AABBs are involved. If a dead simple grid-like floor collision already cannot be solved with a penetration depth based system at all, I am probably at a loss ...