I think I understand the scheme you're describing. Let me restate it to check:

So your tag byte is doing double duty: it identifies both the primitive type and the array nesting depth of the value behind the void*.

A few things worth thinking through:

1. Tag budget math If you have, say, 16 primitive types (N=16), you get M = 255 − 16 = 239 dimensions of nesting. That's plenty. But if your primitive list grows, your max nesting depth shrinks. If you ever need more than ~200 primitives, you collide with your slice tags.

2. The "length at index 0" layout For []T, the void* points to a block where [0] is an int length and [1..len] are the elements. That works, but it means every slice access pays a pointer indirection just to read the length. A more common fat-pointer layout keeps (ptr, len) together in the value struct rather than in the heap block. Is there a reason you want the length inline with the data?

3. Nested slices For [][]T, each inner slice is itself a void* with its own tag. Does the outer slice's memory contain (tag, void*) pairs? Or do all inner slices share the same tag (N+1) and the outer tag (N+2) just means "array of arrays"? If the latter, you lose the ability for a [][]T to hold rows of different types.

4. Homogeneity vs. heterogeneity If []T means "slice of the sumtype," then each element can independently be any variant (int, void, another slice, etc.). That's powerful but means your slice of 1000 ints carries 1000 tag bytes. If you instead want []int to be homogeneous, you'd need separate tags for []int, []float, etc., which explodes your tag space.

5. The void + tag model* This is essentially a manual vtable or tagged union. It's flexible, but every operation needs a switch on the tag. Have you considered whether you want inline storage for small primitives (e.g., fitting an int directly in the pointer word) to avoid heap allocations for simple values?

What aspect are you looking to nail down — the bit-level encoding, the allocator strategy for the slices, or whether this is a sound type-system design?

There isn't one classical name for the exact scheme you described, but it combines several well-known concepts:

Tagged pointer / tagged reference — the ubyte + void* pair itself. This goes back to Lisp (1960s) and Smalltalk, where low bits of a pointer word encode the type, letting the runtime dispatch without dereferencing memory. Your version uses a separate byte rather than stealing pointer bits, which is the same idea just less compressed.

Discriminated union (or sum type, tagged union, variant) — the type system where a tag tells you which constructor/primitive is active. This is the classical name for "void or int or float or ...".

Boxed value — when a primitive like int is heap-allocated behind a pointer with a tag, rather than stored inline in the pointer word.

Fat pointer — usually means (ptr, len) or (ptr, len, cap) stored together, but the term is sometimes stretched to any pointer carrying metadata.

Where your scheme diverges from the classical literature is the specific convention that N+1 means "1D slice of sumtype", N+2 means "2D slice", etc. That encoding doesn't have a standard name — it's a rank-encoded tag or dimensionality-encoded tag, but those are descriptive, not classical terms.

The closest classical analog to that nesting convention is probably nested arrays in APL/J, or the way the JVM encodes array types as [I, [[I, [[[I — where each [ prefix adds one dimension. Your tag byte is doing the same job as those bracket prefixes, just in integer form.

So if you need a name for the whole thing: it's a tagged-pointer representation of a sum type with rank-polymorphic array nesting.