I think what it comes down to is that MLCad's primary function is a model-editor. Sub-models (note: not sub-parts) do not have prefixes on their names, so MLCad simply doesn't support them. It has no way of knowing that the file you imported was a subpart and thus should have the 's\' prefix.
Given the above it's not too surprising that trying to use it like this has unexpected results :-)
My own parser takes this into account: it reads the 'FILE', 'Name:' and '!LDRAW_ORG' lines and when they disagree it attempts to work out the most probable solution. In the case of your file, although the 'FILE' line just gives the filename as 'testparts.dat', because the 'Name:' line reads 's\testparts.dat' the parser concludes that it is in fact a subpart and fixes the 'FILE' line accordingly. Hence if I load the file into my parser it renders both bricks first time :-)
Given the above it's not too surprising that trying to use it like this has unexpected results :-)
My own parser takes this into account: it reads the 'FILE', 'Name:' and '!LDRAW_ORG' lines and when they disagree it attempts to work out the most probable solution. In the case of your file, although the 'FILE' line just gives the filename as 'testparts.dat', because the 'Name:' line reads 's\testparts.dat' the parser concludes that it is in fact a subpart and fixes the 'FILE' line accordingly. Hence if I load the file into my parser it renders both bricks first time :-)