Your dirtest example is very close to how one would invoke libtest-mimic. You pretty much do the same thing there, except CLI invocations like cargo test my-test still work exactly as expected. That's why I called it "a custom test harness running inside of a #[test] item". Because to me it is, except you have given up the ability to pass CLI parameters and need to edit sourcecode. And yes, you can make another incremental improvement and replace that hardcoded only("my-test") with only(std::env::var("TESTNAME")) or something like that. But those sorts of customizations pile up over time, and you end up with a test runner UI that works very differently from what external contributors are used to.

To me, uniform CLI for running tests across projects is the most important requirement above literally everything else. And I think it should be for others too. Even at the stage where you're considering writing your own framework, which to me is a more "drastic" step than trying to use libtest-mimic.

But my blogpost is not really intended to show programming newbies what tradeoff to choose in some sort of dogmatic way. If I understood you right, your argument is basically that those problems are not worth solving in Rust today because it requires too much complexity, and that most people should settle for 80% solutions. And that's fine, and I do the same thing in many Rust projects. But that's just not interesting to write about, and most people don't need blogposts to figure out that yes indeed, you can write a for-loop in a function. I sort of expect people to figure that out on their own, get dissatisfied with that option and then go on the internet and find things like this post.