ZDoom

I cannot remember why I moved it but there must have been some reason for it. At the very least, P_FreeLevelData needs to clear spechit as well because whatever is in there at that point will inevitably become invalid.

Graf Zahl wrote:P_FreeLevelData needs to clear spechit as well because whatever is in there at that point will inevitably become invalid.

I was thinking about the same. I fear that it may hide an issue when spechit should be cleared in other cases, not on the first tick.
Anyway, clearing temporary data between maps seems reasonable.

I'll have a closer look this evening. Right now I cannot say anything more.

Looking through the code I think I remember what was the problem: PIT_CheckThing is doing a lot of stuff it shouldn't, if it had been cleanly implemented. Unfortunately it is so full of side effects and bad behavior that it can easily result in a recursive call of P_CheckPosition and leave a filled spechit array behind. And this can turn nasty if there is a portal in the set.
Moving the two array clears below the BlockThingsIterator loop was supposed to clear this residual garbage. Unfortunately this does not account for the exit conditions above and still leaves some garbage behind in other cases.

I wish this could be solved the clean way, i.e. by making the spechit array local to the current function call. Sadly with all the side effects that need to be considered here this is not possible. For example, when something along the way results in a teleport this needs to clear spechit of the current P_CheckPosition call.
This entire code is a mess beyond hope that cannot be fixed because it's one cornerstone of how Doom works.

Meaning that in order to fix it, one would have to carve out at least half of the entire source code potentially?

To fix the movement code you'd have to write a new engine. The original Doom code was so poorly conceived that most attempts at sanitizing it are doomed to fail because they'd break the very essence of it.