Since soft assertions prevent the code from raising AssertionError, chaining of different assertions is possible.
It works fine when assertion val type remains unchanged during chaining.
Chaining like raises().when_called_with().is_equal_to() changes the type of val after .when_called_with() execution.

Normally, this code allows us to chain error message assertion:

exception.py

if issubclass(type(e), self.expected):
    # chain on with error message
    return self.builder(str(e), self.description, self.kind)

However, if exception is not raised or wrong exception type is expected then we do not reach this code and val type remains unchanged. Eventually, we have some callable function as val before error message assertion.
This behavior leads to following scenarios' failures:

Case 1

with assertpy.soft_assertions():
    assertpy.assert_that(lambda x: 1/x).raises(ZeroDivisionError).when_called_with(1).matches("zero division")

Here we get TypeError: val is not a string from type validation of matches method.

Case 2

with assertpy.soft_assertions():
    assertpy.assert_that({}.__getitem__).raises(RuntimeError).when_called_with("key").contains("key")

Same thing here with TypeError: argument of type 'builtin_function_or_method' is not iterable

So I think we need to stop processing chaining assertions after when_called_with failure to prevent our program from failing.