There are different things we may have that occupy more than one shader location/binding:

• external texture taking multiple bindings - What binding numbers are used by an external texture binding? #1721 .
• resource arrays - Support for arrays of textures #822. In Vulkan, these occupy a single binding, using another dimension in the binding space - the array dimension. In D3D and Metal (argument buffers), the arrays are placed continuously into the binding space. Bindings are currently unlimited.
• vertex attributes that are arrays or matrices - Allow mat2/3/4 as attribute types #1652. In native APIs the vertex attribute location is pointing to the first column/element, and the rest are allocated continuously. The attribute locations are currently upper-bound by the limit - Restrict GPUVertexAttribute.shaderLocation < maxAttribs #1423.
• shader input/output being arrays or matrices (internally between stages)

For each of these, we can make a decision to either allocate consecutive indices (starting with the one that user specified), or shadow-allocate the locations/bindings internally. The former would be consistent with native APIs. The latter is possible if the implementations have to re-map all the bindings (and/or locations) anyway.

It would be good if our story on the subject was consistent.