OK, I’ve gotten to the bottom of this issue and it turns out that it is a long standing issue.
The problem is that when a Land command has the lat/lon specified the vehicle will always try to fly to that lat/lon at the current altitude-above-terrain completely ignoring the altitude frame set in the command. This was likely done on purpose a long time ago before Mission Planner (and other GCSs) supported setting the frame individually for each command.
I’ve created a PR to change the behaviour so the vehicle will obey the altitude frame specified.
Of course the scary thing about your experience was that the vehicle flew up to 40m (and it would have flown much higher if the altitude fence hadn’t been enabled). This was caused by the vehicle attempting to do terrain following with a rangefinder that was incorrectly reporting that it had a good altitude when it didn’t. This problem stems from a limitation in the Benewake TFmini (which is what I think you’re using) in that it does not report a “reliability” like the TF02 (and perhaps other Benewake lidar do) meaning that the driver doesn’t know if “0” is a valid reading or not… I might check with Benewake about this though and maybe their lidar will never report 0 if the distance is valid.
… by setting the RNGFNDx_MIN_CM to 10 you effectively told the driver that 0 was an invalid reading and resolved the problem. In general RNGFNDx_MIN_CM should never be set to zero… perhaps we should enforce that somehow.
EDIT: the above PR actually would have avoided the problem you saw from happening I think even with the RNGFNDx_MIN_CM set incorrectly.
EDIT2: In case you’d like to test this here is a binary for the MatekH743-bdshot which is Copter-4.2.1 with this patch applied. It would be most interesting if you could set RNGFND1_MIN_CM back to zero and test what happens. Be ready to re-take control of course but I suspect it will display an error message but still perform the land correctly.