Requested feature
Call should have a way to specify an explanation added to the error message for what an expectation tests, but it currently does not. E.g. it could support a reason("to ensure foo was tested") function on Call which would change the errors to read "expected call to ensure any bunny is always fluffy at" from "expected call at".

Why the feature is needed
It is sometimes hard to differentiate between a mock intended to enable a test later in the testcase and a mock that itself is intended to test something. Even when that is made otherwise obvious, e.b. by a Times(0), that does not document the reason.

While a comment can be used to locally document that, it is more helpful to have it included in the error, to quickly know the reason, without needing to look up the code.

If the amount of mocks is small per test, the test name can be used to document the reason, which will be visible in the error output. However that does not work if the amount of mocks is more than a few. I'm unsure if reducing the amounts of mocks needed should be high a enough priority to make this feature unnecessary and misleading.

Currently there is a way to customize the error message of a mocked Call failing the test, but it is on global level instead of per Call / EXPECT().

Many testing frameworks provide assertions taking an argument that is included in the error message for the test, this would be along that line. Example from https://pkg.go.dev/github.com/stretchr/testify@v1.11.1/assert : assert.Equal(t, a, b, "The two words should be the same."). The reasoning in https://go.dev/doc/faq#testing_framework against assertions does not apply here, as the error message currently can not be sufficiently customized so it already fails on that ground and assertions are already provided with Matcher functions.

Matcher functions might be another place where this functionality might be useful, I have not sufficiently thought about that.

I would appreciate someone else their reasoning about if this is a good idea and how it will affect quality of test code. Especially in respect to if instead code should be structured to not need this feature and if big code bases usually achieve that. Or if big code bases usually have the problem that you need to understand the code to know which EXPECT is an important test.