You can have a same-shape constraint between packs at different lexical depths in the generic signature. The restriction in the proposal is using the term "depth" differently, to describe nested pack expansions.

For example, I can write this:

```
struct Outer<each T> {
struct Inner<each U> where repeat each T == each U {}
}
```

The requirement `repeat each T == each U`

states that `each T`

and `each U`

are exactly the same pack; `T`

and `U`

have the same shape, and each element of `T`

is equivalent to each element of `U`

at the same position.

You can also state that two packs have unified elements using an intermediate scalar type parameter:

```
struct Outer<each T> {
struct Inner<each U, Element> where repeat each T == Element, repeat each U == Element {}
}
```

The requirements `repeat each T == Element, repeat each U == Element `

state that the elements of `T`

and `U`

are all equivalent, but `T`

and `U`

are not required to have the same shape. There's no way to write a requirement that unifies all elements of `T`

and `U`

without an intermediate type parameter, e.g. `Element`

in the above example, but such a requirement is possible theoretically through requirement inference involving nested requirement expansions:

```
struct Unify<Element, each T> where repeat each T == Element {}
func unifyAllElements<each U, each V>(_: repeat Unify<each U, repeat each V>))
```

The application of `Unify`

inside of a pack expansion would infer the requirement `repeat each T == Element`

where `Element := each U`

and `each T := Pack{repeat each V}`

for each element of `U`

. This effectively says that all elements of `each U`

and `each V`

are the same type, but without requiring them to have the same shape. Concretely, given `each U := Pack{X, Y, Z}, each V := Pack{A, B}`

, we end up with 6 expanded requirements:

```
repeat Unify<each U, repeat each V>, each U := Pack{X, Y, Z}, each V := Pack{A, B}
-> Unify<X, A, B>, Unify<Y, A, B>, Unify<Z, A, B>
-> A == X, B == X, A == Y, B == Y, A == Z, B == Z
```

This isn't a requirement that's supported in our generics system - each mention of `each U`

or `each V`

is effectively reduced to a scalar type parameter, but we have no such type parameter in the signature of `unifyAllElements`

to reduce these types down to.

So, `repeat Unify<each U, repeat each V>`

has a nested pack expansion, and the proposal is using "depth" to refer to the nesting level of these expansions. The outer expansion that iterates over `each U`

has an expansion depth 0, and the inner expansion that iterates over `each V`

has an expansion depth 1. The inferred requirement ends up capturing `each U`

at expansion depth 0, and `each V`

at expansion depth 1, and equating pack elements at different expansion depths is when we can end up with this funky pack element unification with no type parameter to describe the reduced type.