It's not broken. The "legacy" stuff I referred to in passing above I now need to explain a bit more. PDL in about 2000 gained a PDL::Complex class, which has a badly-hidden 0th dimension length 2, which forms pairs of real, imaginary. There are also a number of methods that provide some of the operations that real-valued ndarrays, that know about having the first dimension as real, imaginary. Various non-core modules like PDL::FFTW3 and PDL::LinearAlgebra partly worked around the many limitations of PDL::Complex.

In 2021 I ran with Ingo Schmid's pull-request that partly added support for C99 "native complex" types in PDL, and after quite a lot of bug-fixing, plus fixing up those two non-core modules to work properly with both "native complex" and PDL::Complex.

ctricpy is only for working with PDL::Complex, which you can tell by looking at its "signature" with the leading dimension length 2. After I added the foolishly missed-out type-support for "native complex" in the last few days, tricpy is now suitable for use with native complex data, as you have shown above.

Why does each operation need to "opt in" to support native-complex data? Because if you default to all of them supporting it, stuff breaks, as shown after 2.026_01 was first released: https://sourceforge.net/p/pdl/mailman/pdl-general/?viewmonth=202102

The current state of affairs with PDL and complex numbers is you should only use native-complex types for complex-number data. Don't touch PDL::Complex at all. Don't use ctricpy. PDL::LinearAlgebra and PDL::FFTW3 work correctly with them (unless they don't, in which case please report bugs).