That’s exactly what this is. Philips have a habit of adding that image at the end of the series for some reason (on Siemens, this type of image would be added as a different series altogether). It shows up as a volume with a zero direction vector, but a non-zero b-value. It would be discarded by any MRtrix3 application that makes any interpretation of the DW gradient table, so that it doesn’t interfere in tensor or other calculations. I guess other converters simply discard the volume wholesale, which does have the advantage of keeping things simple.
As to the difference between mrconvert and mrinfo, as @dchristiaens says, it’s all about how much interpretation is performed on the DW gradient table. For mrconvert, essentially no interpretation is performed - it’s passed through to the output unmodified. With mrinfo on the other hand, operations like b-value scaling and normalisation of vectors takes place. I can see that it can get confusing, but essentially what you get with mrinfo is the DW gradient table as it would be interpreted by MRtrix3 applications, unless you use the -raw_dwgrad option, in which case you should get the same as mrconvert would produce.
As to which of these is ‘correct’, I guess that depends on your point of view. The idea in mrinfo is to provide information about the image, as MRtrix3 understands it. This does get a bit messy when using the -export_grad_fsl option, since that’s also a conversion, and I can see that the fact that it behaves differently in mrconvert than it does in mrinfo is a bit weird. I agree it might be better to ensure consistent behaviour for the -grad_export_* options - but I’m not sure whether it’s best to modify the gradient table or leave it as-is (this is relevant for multi-shell acquisitions where the acquisition software is often ‘tricked’ into modulating the b-value by scaling the gradient vectors) - thoughts welcome.