Potential culprit could be the order when gEnemyParty is zeroed out. I remember there was a recent PR for that. I can't find the PR though but I know it wasn't from a recurring contributor.

Was it #5281?

Was it #5281?

I believe so, yes

anohter user on TAH who was seemingly having the smae issue was posting about ti on 8/12/24, so this prdates the #5281 ?

issue sems fixed by remvoing 5664-5667 in battle_main.c, however im not a genius enough to knwo if that breaks other stuff

inncase its helpful, i've also palyed a roudn of battle factory ad a roudn of battle tent slateport wiht my fix an encoutnered no issues

I can confirm this is reproducible on 1.10 if you encounter a roamer, it flees, and then you encounter that same roamer again.

Emulator: mGBA 10.4

Some observations that I cannot make anything out of, but might be useful.

If I put DebugPrintfs before ZeroEnemyPartyMons call in FreeResetData_ReturnToOvOrDoEvolutions function and before UpdateRoamerHPStatus call in ReturnFromBattleToOverworld function, this is the debug log after a roamer flees:

UpdateRoamerHPStatus being called after ZeroEnemyPartyMons might be an issue. If in FreeResetData_ReturnToOvOrDoEvolutions I replace this:

if (!(gBattleTypeFlags & BATTLE_TYPE_FRONTIER))
{
    ZeroEnemyPartyMons();
}

with this:

if (!(gBattleTypeFlags & BATTLE_TYPE_FRONTIER) && !(gBattleTypeFlags & BATTLE_TYPE_ROAMER))
{
    ZeroEnemyPartyMons();
}

the issue goes away, but I don't understand the code fully and assume there is a reason ZeroEnemyPartyMons is being called, so this is unlikely to be the solution.