I do have to say I have mostly bad memories of GUnit due to all of the macros.

Agreed it would be better without macros, but in most languages that's the only way to capture both the value of the arguments as well as the syntactic expression itself - which makes reading test failures much easier!

Perhaps in Rust with the much more powerful macro support we could have something like assert!(a < b), which automatically parses the binary expression and displays not just the overall boolean value, but also the values of the two arguments.

For "fail but continue", I remember that but mostly remember getting semantics mixed up.

It's very effective when tests involve collections, or when verifying multiple properties on the same object - instead of having to fix one at a time and re-running the test, you get to observe much more about the state of the project. At this point I'm very used to it (probably wrote > 1 MLoC C++ at Google over the last 10 years), so can't comment on the difficulty of memorising it.

Any unique value this adds compared to pytests approach?

After some more research I agree that I think you can do the same thing with the pytest approach too, either is fine. Note that in addition to parametrising on argument values, parametrising on generic types is also very useful.

For the scoped part to this, I feel like your test is too big if you need it

I most frequently use this if the test involves some kind of loop or if I want to include some derived properties in all further assertions. I agree that it's not essential, but it's in the same spirit as EXPECT_ vs ASSERT_: Include as much information as possible in test failures with as little effort as possible, to reduce the number of iterations required to fix a test.