Unfortunately the answer given does not actually properly quantify the landscape of multidimensional datastructures in programming, nor in english. It's significantly more complicated than what they say.
When a normal person, with out mathematical background, is talking about "dimensions", they are talking about dimensions of space/reality. This is typically used when you talk about "how many dimensions something has", as in, does something have two dimensions? Three dimensions? one might say "space is three dimensional"
When you're talking about a multi-dimensional object, such as a vector in the linear algebra sense, you would use ND, as in a 3D vector, or a 2D vector (or vec3/vec3D/float3/float3D), where D stands for "dimension".
When you're talking about a tensor, a more generic mathematical object that encompasses vectors and matrices, for example, in machine learning and physics, and you're not talking about simply the number of elements, but the number of dimensions of the object itself, you're talking about modality, as in a vector is a rank 1 tensor, it has one mode, a matrix has rank 2, it has two modes. Alternatively, these are referred to in a mode sense (mode-1, mode-2, mode-3 etc...).
When you're talking about a generic programming object which may have multiple dimensions, the term is either shape, size, or extent.
Shape is used in Python's Numpy and derivatives of it (such as xtensor in c++).
Size has been used add-hoc and is the most confusing of these terms, it's used in Matlab, but I've seen it used in other random matrix libraries. It's especially not clear in C++, where the term is used normally for the total number of elements in a container.
Extent is used in C++23's mdspan, and the Vulkan API, which has objects like VkExtent2D and VkExtent3D.
Others like Eigen don't even officially have a word for the size of each dimension (since they only deal with matrices and vectors excluding unsupported versions)
One thing to note about extent is that it's often used in opposition to the idea of an "offset". You need a way to differentiate between these two types of objects, the size of each dimension (extent) and the offset within an extent (offset), where an extent can never be negative, but an offset can. This does a lot of things, like allow you to create a bounding box out of an offset and an extent and get semantic compile time argument checking with out having to resort to using named arguments, because you are using the same type for each parameter. Indeed, Vulkan contains a VkOffset2D and VkOffset3D because of this very important attribute, as seen in VkRect2D
// Provided by VK_VERSION_1_0
typedef struct VkRect2D {
VkOffset2D offset;
VkExtent2D extent;
} VkRect2D;
In contrast, while shape can physically fill the same niche as a name for a type that represents what Extent does (you can make a type called "shape" and a type called "offset"), linguistically it makes much less sense (shape is very generic). This isn't as much of a factor in a language like Python, but in a statically typed language, especially one with out named arguments, it becomes an important argument to use extent in place of shape in some scenarios.
Additionally note that the argument that "extent could refer to a 1 dimensional quantity" doesn't make sense linguistically (extent is often implicitly used to refer to all dimensions "extended" of a given subject, not just a single length dimension even outside of programming, the fact that sometimes a word could be used to mean a different thing at a different time is just a part of life and language, hence we have to rely on precedent as well to prime understanding, not just literal colloquial meaning of a thing) and doesn't make sense with regards to other words, such as offset which would face the same problem.
Extents also make it clear we aren't talking about the number of dimensions of an object but the extent of those dimensions, the length size of them, in a way that other terms except for shape, don't make clear.
So ultimately, shape or extent are the only terms with precedent for what you're doing. At least in describing the size of each dimension, I think both do an equally good job at making it clear what each means, for example:
"dimensions": {
"width": 3,
"height": 5,
"depth": 7
}
could also be written as
"dimensions": 3
for a completely different meaning, but you couldn't do the same with shape or extent and have it make sense, shape: 3 and extent: 3 would never mean "3 dimensions", while obviously the above could.
But do note that spans and md-spans use "extents", and C++ containers use the term "size" (and the size_t type is used a lot).
As mentioned earlier, Extent and Size are two totally different concepts in C++, the total number of elements in a container is not the same as the extent/shape of said container.
std::mdspanis accessible to your users.