Wouldn't this be "null" on nested shapes where one of the underlying keys does not exist? (given that you pass null as a string to the parent exception?

(same comment for CoercionException)

I don't understand what it means, could you expand? If the "outer" shape does not match - no "nested" shapes will be checked, right?

For example:

shape([
    'a' => shape([
        'b' => mixed()
    ]),
])->coerce(['a' => []]);

This will result in:

Could not coerce "null" to type "array{'a': array{'b': mixed}}" at path "a.b"
 -> Previous:  Could not coerce to type "array{'b': mixed}" at path "b" as the value was not passed.

If the "outer" shape does not match - no "nested" shapes will be checked, right?

The types will coerce top-down indeed. But if one of the nested children results in a failure, the exception gets wrapped and enriched with the "path" information. It's that $first logic inside the exception constructor which you default to ?? 'null'.

Oh yes, now I see that CoercionException and AssertException should be monadic. How about now?

Only for CoercionException yet, as a proof-of-concept.

And a mandatory reminder: this is still under heavy WIP, I understand it's not a trivial change and I will clean things up during the final git squash.

I don't think wrap()-ing it is the way:

vec(
    shape([
    'a' => shape(['b' => mixed()])
    ])
)->coerce([['a' => []]]);

Could not coerce "null" to type "vec<array{'a': array{'b': mixed}}>" at path "0.a.b"

The parent's exception construction should be more aware of those details from within the child's type exception.
Maybe an alternate suggestion would to make the $actual and $first property nullable for those situations where the value is not available and let that decide the message instead?