neat, but not a best practice at all, which thankfully the votes have reflected haha

Why?

bad practice

very neat

its not nesesarelly as mission of any function is provide back a result of task it was created to do.

This is one of the most elegant solutions, though might not be the most performat one. Consider tail call optimization for this.

Frankly speaking, I doubt that your code is called with wrong arguments. trace is unreliable here, because of shrinking: after finding [27,15,15] QuickCheck tries to find a smaller counter-example, invoking tests with [27,15,14] and, I suppose, some other combinations. That is why you see [27,15,14] in trace output.

test lastDigit [x, y, z]
✘ Falsifiable (after 69 tests and 5 shrinks): 
expected: 3
 but got: 7
NonNegative {getNonNegative = 27}
NonNegative {getNonNegative = 15}
NonNegative {getNonNegative = 15}

Looking at this actually seems to reveal the issue, as logging the input arguments (with trace + show) shows that my code is called with [27, 15, 14] (which ends in 7) instead of [27, 15, 15] (which ends in 3).

Could you please show full test log? I cannot reproduce the issue. Definitely, lastDigit [7,11,2] should be 7.

The following Haskell test case fails for me: lastDigit [7,11,2], expected 3 but got 7. However, checking 7^(11^2) in Wolfram Alpha shows that the last digit is, indeed, 7.