Exposing computed boundingBox information

What is the right level of detail to expose bounding box information?

Fundamentally, an Axis-Aligned Bounding Box (AABB) only requires six values, e.g.:
min(x,y,z) and max(x,y,z)
OR
center(x,y,z) and size(x,y,z)

In practice, most 3D engines expose some level of convenience over operations on AABB objects, e.g. to determine broad-phase intersections, adding and subtracting, or factoring their dimensions into matrix operations for transformation.

As well as that, there are questions of the lifetime of the objects created for this purpose - the timeframe for which objects are valid, when / if they're nulled, or whether things are resolved as being pass-by-value valid (i.e, they're re-creations that are only valid at the time of creation etc)

It seems like in the longer term, a comprehensive spatial web will need a more sophisticated set of 3D math objects, for relating DOMMatrix to DOMPoint, DOMRect etc. - but that seems like a big project that will require clearer use-cases and some initial, basic functionality for people to explore with.

Suggestions

1. Expose DOMPoint model.boundingBoxCenter and DOMPoint boundingBoxExtent directly on the model element
2. Expose a boundingBox as a key-value Dictionary so we see
   DOMPoint model.boundingbox.center
DOMPoint model.boundingbox.min
DOMPoint model.boundingbox.max
   ...but are unable to return radius or other convenience methods
3. Do the up-front work of creating an AABB interface that allows us to expose some selection of values and provides us with a context to supply convenience methods (e.g. intersect, volume, radius etc)

Personally, I think that while (3) is an inevitability, I'd actually lean on the simplest, roughest approach that gives early authors the bare minimum to work with, i.e. (1). I'm aware that can carry the risk of never being able to deprecate it, but I suspect we simply don't know enough about what we want to do the architecture up-front.