As now noted on pryrt's excellent bug report (thank you), this will still work as expected if you switch your inv($m) to $m->inv. This will then engage PDL::Matrix's overload of x, which is what you need here.

I would strongly encourage you not to use PDL::Matrix, because somewhat similar to PDL::Complex, it is full of gotchas. Even though after some head-scratching it became clear what exactly was happening here, it's not particularly clear how to fix it - a keyhole change to the Perl function PDL::MatrixOps::inv to make it ensure the output was the right class would resolve this exact issue. But since that uses lu_backsub for its work, and that is an eye-wateringly complicated Perl function as well, it will not be easy. That function's output variable comes from some PDL::Slices operations.

If someone were minded to at least use git bisect to identify the commit that broke it, that would be very helpful. Even better would be a pull-request that fixes this (obviously with a test, in t/matrix.t), that will use our amazing CI to check it doesn't break anything else in main PDL or known downstreams. A top tip would be that make coretest runs t/matrix.t, with a very minimal build otherwise that allows a very quick dev cycle.

As a hopefully practical (as well as better-performance, because it uses LAPACK) alternative, have you taken a look at PDL::LinearAlgebra?