Hm, the vcat modifications also kick in when there is no UniformScaling around, and then a column matrix is returned instead of a simple vector. hcat is fine though. I'm not sure if there is a simple fix to that, other than reverting that change.

EDIT: I think that's fixed now.

@stevengj Thanks for the comment. I made a second attempt without allocating vectors. The resulting method is more special than the generic hv/h/vcat, so at the end we need to call a function with a different name.

I'm running out of ideas... I had added Number to the signature of hvcat and "promoted" numbers to numbers. Without Numbers in the signature, we have only abstract matrices, so when we call hvcat again it's calling a different method, with homogeneous argument types. With Numbers, we can't call hvcat on the promoted arguments again, because the method calls itself indefinitely.

I was trying to circumvent this by calling typed_hvcat after the promotion, but that doesn't get the dense/sparse logic right (one of my own tests gets it wrong, all other existing tests pass!). The reason seems to be that the sparse concatenation routines don't run by typed_*cat methods, which are called within typed_hvcat. Those don't even return a sparse matrix when you hcat a number with a sparse row vector...

To resolve this, we would need to call straigt *cat, and so the cat bites itself.

So I couldn't get this working without the allocation @stevengj rightly found unfortunate. So I'm fine with closing this, unless fixing the original issue by c4dd694 weighs more than the price we would pay with the allocations. @stevengj @mbauman