If you look at the Krakatoa Velocity RenderElement, you will notice that it has different options to store its data.
It always saves data in Camera space with R representing the X, G representing the Y, and B representing the Z (where -Z is along the camera viewing axis, and +Z is towards the viewer). But the value ranges are different depending on the Use Max Velocity checkbox’s state.
When the checkbox is unchecked, the values are stored As Is, in the range from -Infinity to +Infinity. So if a particle is moving with a Velocity magnitude of 100.0 per frame parallel to the X axis of the screen to the left, it will have an RGB value of [-100,0,0] stored in the image.
But if the checkbox is checked and the Max. Velocity is set to 100.0, the value will be [0.0,0.0,0.0], because 0.0 presents the normalized value of -1.0 moving at 100.0 units/frame to the left, 0.5 means 0.0, and 1.0 means Max velocity to the right! This makes sure that all RGB values are in the 0.0 to 1.0 range, with 0.5 representing no motion along that axis! If the colors were represented in the 0 to 255 range, then 127 would represent 0.0, this a mid-gray color of [127,127,127] means a stationary particle with no motion.
The difference between these two modes might explain why your post-production filter would show incorrect blurring direction - you will have to consult its documentation to figure out what input data it expects, and in what range. Does it use unclamped data in the range from -Infinity to +Infinity? Or does it expect normalized data in the range from 0.0 to 1.0 where 0.5 means no motion?
In the case of RSMB, it actually expects a 2D vector in screen space and in the 0.0 to 1.0 range in RG, and B equal to 0. I am not sure if a B > 0 would have a negative effect on it, but in the examples I saw, the motion data was more or less yellowish, meaning there were positive values for Red and Green, and nothing in the Blue channel. Thus a particle with no motion should have a value of [0.5,0.5,0.0].
In theory, if you enabled the Use Max Velocity checkbox in the Krakatoa Velocity Render Element, and entered the maximum possible velocity per frame in the Max. field to normalize by, then the resulting pass should blur correctly in RSMB. You could also multiply the B channel by 0 before using the pass just in case.
In the following example, I created a Geosphere, covered with a PRT Surface, dumped the Normal into Velocity, and multiplied it by 300.0 to produce 10.0 units of motion per frame.
In the following image, you can see the left VFB showing the unclamped motion, while the right one shows the Max. Velocity of 10.0 result:
If we look at the actual pixel data, the unclamped pixels that appear to be blue on the left side actually contain a negative value of almost -10.0 along the X, but Max VFB has no idea how to draw that, so it clamps it to 0:
In the Max. Velocity pass though, that same pixel has a Red value of nearly 0.0 because that denotes full speed along -X. A pixel in the center of the image would have 0.5 for Red and Green, but 1.0 for Blue because it is moving full speed towards the camera…
Here I disabled the Blue channel to display the clamped image that RSMB would expect as a 2D vector image in the 0.0 to 1.0 range for Red and Green.
You can achieve this in post before using the image by multiplying the Blue channel by 0.0. Of course we assume that Red goes from 0.0 to 1.0 from left to right, and Green goes from 0.0 to 1.0 from bottom to top. If the filter expects the Green to move from top to bottom, we would have to invert the Green channel, but I would not expect that to ever be the case, because Camera space is generally Y up.
Knowing this, try to figure out whether RSMB is being confused by the Blue channel. Looking at the second picture you posted, it appears that you used the Max. Velocity checkbox, and any yellow streaks you see are supposed to be moving to the upper right corner (lots of red, lots of green).