Why not simply roll your own function to construct a diagonal matrix?

function diagm(m, n)
l = size(m)[1]
nd = l * n
d = fill(0, nd, nd);
for j = 1 : n
idx1 = 1 + (j-1) * l
idx2 = idx1 + (l-1)
d[idx1:idx2, idx1:idx2] = m
end
return d
end

where the 0 in the fill would have to be replaced with the zero for your polynomial.

That reads like an implementation detail, not like a hard requirement of Poly{T} where T.

In any case, you can also of course overload cat for your type.

EDIT:

I agree with you in that this probably should not just check for <: Number, but making your type <: Number is a valid fix until this can be fixed in Base. Moreover, polynomials do very much feel like numbers to me, so not having that parent type and all the associated methods available seems weird to me.

Well, if the cat code uses the zero function, then it makes sense to check for Number subtypes, because that’s how zero is defined (in addition to some other types).

I tried to make a system where I do not distinguish polynomials from their coefficients, to get free
multi-variate polynomials (polynomials with coefficients another polynomial) but this did not work (too long to explain here why). In my system I have many numbers: integers, rationals, BigInts, Cyclotomics, field extensions; I think my type system is ok.

I don’t know how your package is structured, but are you sure things break as soon as you add <: Number to the type definition? Because other than that, I don’t see how this could be resolved, if the <: Number check for zero is intended.

In my mind Number means “some subfield of the complex numbers” or perhaps also “element of a finite field”. If you think it should mean “any element of a ring” then that’s a completely different viewpoint.
Anyway, thinking in terms of “duck typing”, I think the logical test should be the existence or not of a zero method. I would like some authoritative answer (like a sound argument why it should not be so).