Some capability resolution, such as for fault handling, winds up calling resolveAddressBits with n_bits = wordBits, and any remaining bits are ignored. In other cases, such as the destination slot for seL4_CNode_Copy, the user provides a resolution depth parameter, and the call to resolveAddressBits is mediated by lookupSlotForCNodeOp, which fails with a depth mismatch if there are any bits remaining.

Individually these seem like reasonable choices, but it leads to code like this: 

    seL4_CNode cspace_root = ...; // freshly allocated 256-slot CNode with no guard

    seL4_CPtr slot_for_copy = 0x23; // arbitrary slot we know is available

    seL4_CPtr slot_for_tcb = slot_for_copy << 24;

    seL4_CNode_Copy(cspace_root , endpoint_for_copy, 8, ...);

    seL4_TCB_Configure(..., endpoint_for_tcb, ...);

I found it surprising that two different CPtrs are needed to describe the same slot! Is there a conceptual-model-explanation that doesn't involve appeal to the underlying implementation?

Also: my current understanding is that the depth parameter is only needed to disambiguate indirections through CNode-containing slots. What goes wrong if the depth mismatch checks are relaxed?