Could you post the whole mpd that you're trying to import? It's just 8 parts, so I assume that it wouldn't be long.
I can't find the problem at this moment while you described it very well.

Hi Sim, thanks for your answer 😃

I've tried to upload a simpler file without submodels that illustrates the mirroring in all directions: https://www.mecabricks.com/en/models/BLvGRQ0wjGy

The dark grey wedge is the original unmirrored part - matrix 1 0 0 0 1 0 0 0 1

According to MLCad's rotation matrix values,
The blue part is supposed to be mirrored along the x-axis (nose to nose, same side up) - matrix 1 0 0 0 1 0 0 0 -1
The red part is supposed to be mirrored along the y-axis (side to side, same side up) - matrix -1 0 0 0 1 0 0 0 1
The green part is supposed to be mirrored along the z-axis (same footprint, upside down) - matrix 1 0 0 0 -1 0 0 0 1

If you check out the Mecabrick-version, the LDRAW import clearly interprets the rotational vectors very differently, and for some reason, the z-axis mirroring is apparently ignored completely.

I don't know if more errors are added when the part is located in a submodel or a submodel of a submodel (etc.), but it seems to me that there are some basic rotational errors that will compound each time a submodel is nested and rotated within a higher level submodel.

Here are the relevant lines in the ldr-file:
1 8 0 0 0 1 0 0 0 1 0 0 0 1 43710.dat
1 1 0 0 -180 1 0 0 0 1 0 0 0 -1 43710.dat
1 4 100 0 0 -1 0 0 0 1 0 0 0 1 43710.dat
1 2 0 -80 0 1 0 0 0 -1 0 0 0 1 43710.dat

The thing that seems to go wrong with the MOC I'm currently trying to import (and the first example) is that I've recreated the wings studs upward in one submodel, copy-pasted and mirrored the build left-right (y-axis mirroring) in the opposite submodel and finally added them to the main model.

This only works half-way with the LDRAW import because the parts are actually mirrored left-right (y-axis mirroring) but for some reason, Mechabricks also mirror the individual parts top-down (z-axis mirroring), like with the red wedge in the second example.

Thanks for the clarification, I can understand it better now.

We maintain conversion data which is not completed yet. But for those basic parts, it should be done whatsoever.
If I open your ldr build in Stud.io, then I can see that something is messed up there either. When you hover over the bricks, it will hover a different area than where the brick actually is for the red, green and blue part. I'm using Stud.io as a reference when I'm entering conversion data.

I asked Scrubs to take a look at it, as he's the maintainer of the importer code.

Hello, please provide the following:

• Screenshot in a LDraw software of what is expected (with axes)
• Ldraw file
  This is the only solution to investigate. I am not too sure if I understand everything but just to clarify, negative scale is not possible in Mecabricks and therefore real "mirroring" neither.

Hm in that case it might not be possible to solve my problem 😦

Here is a link to screenshot from MLCad: http://lsd.bugge.com/wp-content/uploads/2019/09/LDRAW-import-test-2-MLCAD-screenshot.png
And link to .ldr file (will expire in one week): https://filebin.net/6rilw6on9tk3ejjp

(I realized that I'd messed up the axis in the comment above and have just fixed it)

Thanks for the ldr, hopefully Scrubs can take a look at that to confirm his thoughts.

Looks like the boxes are right in Stud.io when you hover over them, but the bricks are displayed incorrectly.
Would we be able to handle negative scale somehow, Scrubs?

Looking at your screenshot, the problem is the one I mentioned above with negative scale to achieve mirroring.
You shall use 43711 instead. This is a design choice to not handle negative scaling as it is always causing issues e.g. inverted normals, and is not possible in real life.