That would be feasible up to an extent. Detecting there are two describe "a" ... in different files is pretty easy, but when we get to more dynamic ones (describe ("should " ++ description) ...), it gets a lot trickier. I think we’d also have to properly handle and detect nesting of describes to avoid false positives.
One of the first OSS projects I worked on was AVA, a test runner for JavaScript, and I was mostly working on the dedicated static analysis rules with ESLint. We had (still do) a rule for detecting unique titles, but it was so hard to get that right because that’s kind of a harder thing in static analysis (even more so in JavaScript and the way tests could be generated with that test runner).
We at some point decided to enforce this by the tool itself because it was the only tool really able to tell whether there were duplicate titles. I proposed the same change to elm-test (on the same day as for the other proposal, didn’t remember that!), and we since then have that feature in elm-test. Sorry/not sorry for the pains that has caused people 
Anyway, that is to say that elm-review could help out a bit, but not perfectly. And I guess in this case it would only be useful for the migration, so the value is short-lived. Sorry for the maybe unneeded trip to memory/history lane 
If that is the problem, I guess a nice solution would be for elm-test-rs to list all the problems instead of reporting them one by one, as @neurodynamic suggested too. Also, using the watch mode should help the flow here.
Also, I think it would be very nice if both elm-test-rs and rtfeldman/node-test-runner could agree on this behavior (one way or another), so that choosing one tool over the other is up to the user. I feel like they are so close to each other that it’d be a shame to differ on this tiny piece (but that could fail the tests when run when one tool and not the other).
I think the elm-tooling CLI intends to support it when it gets released.