Just to make sure this is the best solution, some alternatives might be:

1. Drop the abspath business, use invocation_dir always -- i.e., disregard the cwd.
2. Keep the current behavior -- they do change the cwd after all.
3. Reset the cwd ourselves in opportune times.

2 & 3 are probably not good ideas, but 1 does make sense to me, I'm not sure we should really try to adapt to changing cwd after startup...

Drop the abspath business, use invocation_dir always -- i.e., disregard the cwd.

That's a good idea, but it would probably require deeper changes in excinfo.getrepr (which only supports abspath currently).

but 1 does make sense to me, I'm not sure we should really try to adapt to changing cwd after startup...

Not sure, the use case presented seems reasonable to me, a fixture is changing cwd during setup and restoring it during teardown. And the problem also manifests itself if we use monkeypatch.chdir.

OK, if changing to be relative to invocation_dir is too hard, LGTM. Would maybe add a comment like:

# excinfo.getrepr() formats paths relative to the CWD if `abspath` is False.
# It is possible for a fixture/test to change the CWD while this code runs, which
# would then result in the user seeing confusing paths in the failure message.
# To fix this, if the CWD changed, always display the full absolute path.
# It will be better to just always display paths relative to invocation_dir, but
# this requires a lot of plumbing.

BTW, presumably this is a problem also for other places that call ExceptionInfo.getrepr (if there are any)?

Backport: #7285