Ok so if I understand correctly,
1) if you render using the particle interface/instances, RS will render with moblur but it takes a long time
2) if you render as meshes, RS is much faster but it won't render with moblur
3) if you render as meshes using the map channel 20 workaround, you get a fast render with moblur but it's not consistent across all frames
Issue (1) sounds like a RS issue. Once tyFlow passes data to RS, it is no longer involved in rendering. In other words, once buckets begin, tyFlow is not doing any work any more. I know there was an issue in VRay, where using Embree with millions of tiny particles would take much longer due to the way instance bounding boxes are queried at rendertime. Perhaps RS has a similar issue.
(2) makes sense and is expected behavior.
Why (3) is not working is more curious. If RS is indeed using the mapping data to calculate moblur, then topological changes should no longer matter because it's not sampling points in time to figure out geometry deformations, instead it should just be implicitly moving vertices along the velocity values in the mapping channel. Perhaps, due to the fact that this velocity/mapping workflow is somewhat of a workaround, they have an internal switch that is still activating when topology changes are detected, even though for your use case such a switch could be ignored because topo changes wouldn't matter.
Either way, tyFlow seems to be doing all it can to get vel data to RS. The remaining issues seem to be things that need to be sorted out by RS.
If you really want to dig in, once you assign your mapping values to particles and convert them to a mesh with a Mesh operator, you can use MAXScript to query the mapping values of particular faces and such...just to be sure the geometry is getting the correct velocities values assigned to the map channel of your choice. Also since RS has a spinner which allows you to define which mapping channel will contain the velocity data, you could set that to whatever channel you want - doesn't necessarily have to be 20, that's just what tyFlow uses internally. Make sure the channel matches whatever you set in your Mapping operator as well.
A final note: it's possible the RS devs have assumed that a a velocity-containing map channel will have an equal number of map vertices as vertices in the mesh. Maybe that's what they're using as their criteria to either accept or reject the data in the channel. When doing a regular Mapping override on particles though, the number of mapping verts in that channel is not guaranteed to match the number of verts in the mesh. Only the face counts are guaranteed to match. This is consistent with how all mapping works on meshes...but may not be consistent with the way RS expects the data to be arranged. That would have to be confirmed with the devs.
1) if you render using the particle interface/instances, RS will render with moblur but it takes a long time
2) if you render as meshes, RS is much faster but it won't render with moblur
3) if you render as meshes using the map channel 20 workaround, you get a fast render with moblur but it's not consistent across all frames
Issue (1) sounds like a RS issue. Once tyFlow passes data to RS, it is no longer involved in rendering. In other words, once buckets begin, tyFlow is not doing any work any more. I know there was an issue in VRay, where using Embree with millions of tiny particles would take much longer due to the way instance bounding boxes are queried at rendertime. Perhaps RS has a similar issue.
(2) makes sense and is expected behavior.
Why (3) is not working is more curious. If RS is indeed using the mapping data to calculate moblur, then topological changes should no longer matter because it's not sampling points in time to figure out geometry deformations, instead it should just be implicitly moving vertices along the velocity values in the mapping channel. Perhaps, due to the fact that this velocity/mapping workflow is somewhat of a workaround, they have an internal switch that is still activating when topology changes are detected, even though for your use case such a switch could be ignored because topo changes wouldn't matter.
Either way, tyFlow seems to be doing all it can to get vel data to RS. The remaining issues seem to be things that need to be sorted out by RS.
If you really want to dig in, once you assign your mapping values to particles and convert them to a mesh with a Mesh operator, you can use MAXScript to query the mapping values of particular faces and such...just to be sure the geometry is getting the correct velocities values assigned to the map channel of your choice. Also since RS has a spinner which allows you to define which mapping channel will contain the velocity data, you could set that to whatever channel you want - doesn't necessarily have to be 20, that's just what tyFlow uses internally. Make sure the channel matches whatever you set in your Mapping operator as well.
A final note: it's possible the RS devs have assumed that a a velocity-containing map channel will have an equal number of map vertices as vertices in the mesh. Maybe that's what they're using as their criteria to either accept or reject the data in the channel. When doing a regular Mapping override on particles though, the number of mapping verts in that channel is not guaranteed to match the number of verts in the mesh. Only the face counts are guaranteed to match. This is consistent with how all mapping works on meshes...but may not be consistent with the way RS expects the data to be arranged. That would have to be confirmed with the devs.