Ummm, just realized that track_caller is only available from Rust 1.46 and and the MSRV is 1.40.

I can either remove it or, or add it conditionally with a cfg_attr, like done here, for example.
This will require an extra build time dep on something, like rustc_version or autocfg.
Will do this happily if a maintainer agrees; didn't want to add another dependency without approval.

I like these changes in combination with #1982, however you should probably split this PR into multiple PRs.

Sure, no problem.
According to any specific criteria, or just to make it a bit more digestible?

Yes more digestible is good :)
Based on your bullet points and what belongs together with regards to content, I'd say:
One PR for everything that belongs to the testing framework (first 5 bullet points). And then one PR for each of the last 3 bullet points.

Sure thing.
Will leave this PR with the start of the and split off the rest

Split off macro changes into #2033
Most of the tests changes are in #2034
(I left of the ls changes since that file is huge and incomplete)

I love this change, many thanks :)

it is possible to write some unit tests?

Sure. Is there a test suite for the test utils?

Write a rust unit test
like in
https://github.com/uutils/coreutils/blob/master/src/uu/head/src/head.rs#L515

I meant to ask if it's a standard practice to test the test utils themselves.

I'll add some

could you please fix the conflict? thanks

@sylvestre Rebased over master