I’m curious about what you mean, both in terms of “resizable” and “slices”. In particular:
Do you want edges that are:
 Smooth? (widening a row widens all rows)
 Ragged? (widening a row widens only that row)
 Sparse? (cells may be absent anywhere)
By your use of “vector”, I suspect “smooth”, as the rest likely require an indirection. But then, what kind of resizing?

Fixed in one direction, growable by any amount in another, origin is a corner?
In that case, “image scanout order” would likely work well (LTR, top to bottom)

Growable equally in two directions, origin is in a corner?
For that, perhaps progressivelylarger “L” shapes, possibly alternating direction depending on how you want iteration to behave.

Growable equally in all directions, origin is centered?
Maybe a spiral would work best.

Growable in order to hold more detail, origin is on a corner?
A Hilbert curve is likely to work well.

Same, but centered origin?
Perhaps an Htree
Do you plan on lots of iteration, in which case 1, 2, or 3 would likely be efficient? Exploiting locality, which makes 4 a possibility? Slicing on arbitrary boundaries, where 1 is probably more efficient than anything else?
I honestly suspect that there’s no sensible option for a “canonical resizable 2d vector”, because “resizable” has so many different options (with disjoint performance and behavioral limitations) that “canonical” seems to become impossible.
And that’s ignoring other things that, say, a map or tile grid would want  for example, a tile grid would likely want more than one of these, maybe using fixedsize scanout tiles at the finest detail for fast distance calculations from indexes (and lookups with those), while using a sparse Hilbert curve at a zoomedout level to keep stuff likely to be accessed together nearby.
That’s not getting into more exotic stuff, like uniformly increasing the detail in one dimension (0 and 1 subdivide the field into two rows, 01 and 11 then double the vertical resolution by sitting after 0 and 1 respectively, etc).