I disagree, I think it should be

mod(z::Complex, n) = Complex(mod(real(z), n), mod(imag(z), n))

Since this defines mod recursively, you can just let mod of a Real coefficient to handle the dispatch

Yes, that's a reasonable further generalization, although I would be more conservative and restrict it to

mod(z::Complex, n::Real) = ...

If n is not real, then splitting the computation into real and imaginary parts makes less sense (especially since Complex(a,b) expects real arguments).

Edit: sorry I was mistaken in my last post.

I don't quite see the argument for restricting the dispatch though, if it errors, then it errors, why restrict the dispatch?

And why is Complex(1+im,1-im) not allowed? Nested complex numbers are quite reasonable.

The problem with dispatching to something that is unlikely to ever be implemented is that the error message is needlessly confusing, both to users and to future implementors — if we want to support mod(::Complex, ::Complex), we will add that method (ala #35374), opposed to implementing mod(::Real, ::Complex).

As for generalizing the Complex constructor, that's a better subject for a separate issue.

Also, if n is not real, the return value is not necessarily Complex. For example, if n is a quaternion then the return value would not be Complex.