This is a known limitation of PFlow + Krakatoa.
Basically, in PFlow, when a Shape Instance brings its own material, the PFlow particles do not “know” about it via a particle data channel. When Scanline or VRay renders the PFlow, PFlow combines the existing meshes into one (or more) big meshes, gets the materials of the mesh instances and combines them into a flat Multi-Material, reworks the Material IDs of the faces to match, and passes the resulting meshes and material to the renderer.
But Krakatoa does not render the meshes, it renders the underlying particle data, so it needs a particle data channel (MtlIndex) that tells it which of the flattened PFlow Mutli-sub material entries to use for each particle. If PFlow has no direct knowledge of that, Krakatoa cannot get it either. Actually, since the MtlIndex defaults to 0 when not set explicitly, Krakatoa will render with the first material found in PFlow, and it is not easy to predict which material will be in that slot.
On the other hand, when PFlow contains any of its Material operators, the particle data channel MtlIndex stores information about the material of each particle, and when PFlow is rendered by Scanline or VRay, PFlow builds the combined meshes and materials based on that data. Each particle can have only one material. When Krakatoa asks the particles for their materials, PFlow has that information stored in the MtlIndex channel, and Krakatoa is able to evaluate the material tree for each particle, and get a valid color. The MtlIndex can also be saved to PRT, and then used by a PRT Loader to distribute a multi-sub material to PRT particles.
Unfortunately, this means that if you add a Material Static operator and pick a multi-sub material containing all the materials used by the shapes you had, they won’t necessarily match the shapes if you Cycle, or use Random distribution. Also, if a shape had N sub-materials, a particle point cannot represent all of them, just one.
The theory, if you have one material per shape object, and you group them and pick the group as the source, and you don’t check Multi-Shape Random Order, then the shapes will be taken in a round-robin manner, cycling through the list. If you make a sub-material matching that order and assign to the PFlow via Material Static with Cycle enabled, the mesh rendering and Krakatoa rendering will match the sub-materials assigned…
Alternatively, if you save the PFlow to PRT and include the ShapeIndex channel, each unique particle will be saved with a ShapeIndex representing the indices on the list of possible shapes. You could then use Magma to dump the ShapeIndex into the MtlIndex channel, and assign a Multi-Sub Material with the matching order to the PRT Loader to render each particle with a color from the material corresponding to each shape.
Hope this helps.