It's kinda hard to tell what you need from your description. Are "fake-moving" the mobjs on off-tics, and then correcting the positions at the next frame? In other words, do you calculate tic 99.4 mobj x and y positions, then correct them on tic 100? Are you actually moving the mobjs to mid-tic positions in the simulation, or only for rendering? And, finally, if you are rendering tic 99.4, do you forcibly render tic 100.0, or is it possible that the next render might occur at tic 100.2, skipping tic 100.0 altogether?
In other words, you may not render tic 100.0, but you always calculate it, right?
How do you store the interim momentum for that imp, from tic 99 to tic 100? Are you actually running the simulation, and doing mobj->X = mobj->X + (delta / interp_diff)? Are you really changing the standard mobj vars by interpolated amounts, and then backing out, and calculating the actual tic with previous values?
Sorry for my ignorance, but it's interesting stuff. Without knowing the specifics, seems tome that there's still not very many places where a mobj gets moved. Even if it's more than one, is it a big cost to dup some code, call an inline func, or even a normal func? Surely you'd only need to had a few lines per movement, right? Anything is better than iterating all the mobjs per tic.
I don't suppose you could use P_SetThingPosition? That would cover the non-Mobj::Think cases, if I'm not mistaken.