In that particular case, Shape is an abstract type, so one approach would be to simply declare a subtype that adds metadata, but contains another shape and delegates to it for geometric primitives. Then it will work fine with array methods.
In the case of this particular package, I would caution you that we found in hindsight that working with a Vector{<:Shape} performs poorly. See this discussion on a related topic: Allocation and slow down when # of types involved increase (slower than C++ virtual methods) - #2 by jling … I’ve been meaning to re-work it with something like the approach in GitHub - YingboMa/Unityper.jl, emulating C union types to avoid the general case of dynamic dispatch.
I would also say that the KDTree implementation in that package might be better off returning an index into an array of shapes, so that you can simply store metadata about each shape in another array. In general, I think that this package needs some re-working and the difficulty of using it with metadata is a symptom of that.