I think there's a lot of value to gain in eliminating this inconsistency from the ecosystem, to have an actual idiom of the order of "actual VS expected" or "expected VS actual" in assertions.
Because the "actual VS expected" case reads more naturally, and because it is also the most common, I propose changing the error message of a failing assert_eq! to "actual VS expected":
assertion `actual == expected` failed
actual: "a"
expected: "b"
If ~1/3 of the uses choose one order, and the other ~2/3 use the other order, I don't think that's enough of a consensus for us to codify. It would be incorrect a lot of the time. Also, in my experience, when a programming language does choose an order for expected vs actual, my personal experience is getting this wrong a lot of the time (and seeing others get it wrong a lot of the time). So I think rust's approach of not choosing a canonical ordering for this is better.
I'm both then since I see both orders used in my personal projects - mostly because there's no better indication from the compiler which value should go where. I'd stick to one given the indication.
I tend to do actual, expected because actual is usually just a variable reference while expected can be a large literal or other more verbose expression and the last argument is far more amenable to reformat splay than the former (IMO).
It's worth checking out the design of googletest - Rust which uses matcher expressions to make it more obvious that the right side is the expected value (e.g. assert_that! documentation) and also it has advanced matchers that provide more detailed error messages, printing subexpressions wherever Debug is implemented (matches_pattern!). It also adds its own test runner that you may optionally use to support tests that useResult for failures instead of panic-based assertions or support non-fatal assertions to be able to see multiple failures instead of stopping at the first.
Those proportions are not indicative of consensus, they are indicative of ambiguity. An ambiguity which hurts understanding of test output.
As to which should be picked, I wouldn't be upset if someone flipped a coin. Non-ambiguous would be better than the status quo. That said obviously it should be (actual, expected) as it is alphabetic.
jUnit and related use the opposite order for a similar reason: they're assuming that expected is often a small literal, and actual is often a function call with a bunch of parameters (the call that's being tested). This is also the documented convention used in googletest for other languages, though apparently not the Rust port as mentioned above?
I've rarely seen any test framework for any language which documents the order as actual, expected - most either don't assign a specific meaning or use expected, actual.
What if neither argument is the actual or expected one? For instance, if I'm writing a zip_eq for slices and assert they both have the same length? And what about assert_ne?
I'm not strongly opposed, just curious whether these questions were considered?
In those cases the actual/expected labels become roughly as meaningful as left and right. For assert_ne the labels could become unactual and unexpected, or perhaps they could be left as is.
Not familiar with the C++ version, but for the Rust version the second argument allows matchers, so the distinction there between the first and second argument can't be easily removed.
Changing the message will not be an effective way of eliminating inconsistency in the ecosystem: most people will not notice, so we'll just be making code worse.
If this is something that could be linted on, perhaps, but otherwise this is not a good idea. There is clearly ambiguity in the ecosystem, you cannot just force consensus through a behavior change.
Furthermore, not every assertion case has a clear expected/actual, sometimes the thing is indeed just "are these two things the same".
A better proposal that helps eliminate confusion would be to add expected= and actual= disambiguators to the macro, e.g. assert_eq!(expected = foo, actual = bar), which change the displayed error message. I'm not sure if it pulls its weight (it feels verbose to me), but it would allow for folks to opt in to expected/actual messaging. I certainly have times where I wish the assertion error message told me which was the expected value.