[-1, -2]

:     -<< [[1,2], [3,4]]

    [[-1,-2], [-3,-4]]

This is assuming that AoA is treated as a two dimensional shape, of course.
One could imagine pointers to things that might or might not have the
right role to function as a subdimension, but the bias of hypers is
towards processing the leaves, not forcing the top level to (in this
case) numerify.

:     -<< [[1,2], 3]

    [[-1,-2], -3]

Basically, unaries don't have to worry about reconciling different shapes.
They just recurse as much as is "reasonable", whatever that is.

:     [[1,2], 3] >>+<< [[4,5], 6]

    [[5,7], 9]

:     [1, 2, [3]] >>+<< [[4,5], 6]

Same as

    [1 >>+<< [4,5], 8, [3] >>+<< ()]

which gives

    [[5,6], 8, [3]]

I'd expect, maybe with a warning on 3 + undef, unless we default to
the identity value trait for + instead of undef.

    -<< [1, 2]
    -<< [[1,2], [3,4]]
    -<< [[1,2], 3]
    [[1,2], 3] >>+<< [[4,5], 6]
    [1, 2, [3]] >>+<< [[4,5], 6]

        hyper recurses at least one level, and then tries to match the
        type of the hyper'ed function on each element. If the type does
        not match, more attempts are made at recursion.

        If at any point the shapes of the current node is different from
        it's corresponding node in the other structure, then a binary
        function is applied regardless of type (resulting in coercion or
        a fatal error).

Depends on what you mean by "match the type".  By one definition, an
array matches the type of +, so it should just hyper on the length of the
array, which is not what people are going to want generally.  I think you
have to try to recurse first.

:       If at any point the shapes of the current node is different from
:       it's corresponding node in the other structure, then a binary
:       function is applied regardless of type (resulting in coercion or
:       a fatal error).

That doesn't do dimension extension of scalars.  We want this to work

    1 >>+<< [1,2,3]

at any level in the hyper, but by the definition above it would add
1 to the length of [1,2,3].  Perhaps there's a Hyper role that says
whether a container can hyper, or defines a function that returns
some kind of hyper conformability type, so that scalars, arrays, and
hashes can be recognized, and maybe other types added.  I guess what
we're saying is that hyper does a mapping from named type to a general
structural type and then does MMD on the structural types.

Or maybe we just treat Item, Array, and Hash roles as structural
types, and let people add other MMDs if they want hyperdispatch to
other structural types.  Though this is getting dangerously close to
letting people change the parallel semantics of hyper for individual
named types, which is something I want to discourage, if not disallow
outright.  So I'm inclined to make named types pick one of the Big
Three to behave as before hyper ever sees them.

Though there could be a pecking order.  For instance, a match object
can do both the Array and Hash roles.  For hyper, it first tries to be
an Array, then a Hash.  If it's matched up against an Item or an Array,
it does Array.  If it's matched up against another Hash, it does Hash.

For now, I think we can just hardwire the analysis in terms of "does":

    given $obj {
        when Array { participate_as_array() }
        when Hash { participate_as_hash() }
        default { participate_as_item() }
    }

or maybe it's

    given $obj {
        when Ordered { participate_as_list() }
        when Hash { participate_as_hash() }
        default { participate_as_item() }
    }

to admit un-indexable lists.