This sounds like a validity interval issue - I have seen the RealFlow mesh loader doing this, and I have seen mental ray doing this with other kinds of objects, but I don’t have a precise solution, just some things you could try.
The idea is the following: Every object in Max (be it a primitive, a modifier, a material, a helper, a light etc.) defines something called a validity interval. It basically describes to Max for how long the respective object can be considered valid without the need for an update. This system allows Max to be “lazy” in updating object if they are not changing. For example, if you create a Box primitive that is not animated in any way, its validity is set to “Forever”. If you keyframe its Height from frame 0 to frame 100 to change from 100 to 200, the validity interval will be collapsed to return the current time only within the range from 0 to 100, but would be valid before frame 0 and after frame 100 if Out Of Range types for the Height are set to keep the value constant (which is the default). So asking for the mesh to display or render outside of the interval from 0 to 100 would return the last known mesh and be faster. As mentioned, this applies to EVERY object in Max, and when you combine such objects, for example have a Box primitive with a Bend modifier and an animated material, the validity interval of the scene object becomes a combination of the validity intervals of all participating components. This usually leads to the object being force-refreshed on each time change.
So when a 3rd party object starts misbehaving because it doesn’t tell the renderer that it must be updated on each frame, you might get an animation stuck on the last frame that got updated. A possible way to break the validity is to add a modifier (e.g Bend) to the modifier stack and set a key on the first frame with a value of 0 and another key on the last frame (or far far away in time, does not matter) also with 0. Although the Bend is not bending, its validity interval is collapsed to current time only because Max sees a keyframed track in it and assumes it needs to update the whole stack. If the validity interval is indeed the reason for the RealFlow mesher to not update, this should make it work again in mental ray.
If the cause is something else, then this would have no effect. In that case, let us (and Next Limt!) know that it is not working…