I would recommend starting as small as possible. Try to report something, then to remove all false positives raised by it. Then try to report some more and to remove false positives again, and so on until you're out of ideas or when it becomes too difficult. In practice, we could integrate and publish this with even the smallest amount of reports that brings value and doesn't have false positives.
I think the easiest would be look at whether elements that are explicitly tuple values have one member that is never being accessed. If you lose the trail of how a tuple is being used because the code is becoming too complex, don't report it. False positives are a bane for users - because it hinders them from writing code they want/need to - but false negatives not so much, especially for such a rule.
I would recommend against copying the tests from NoUnused.Patterns. Take inspiration but no more. Start with a couple tests that you think are feasible and focus on those. elm-review rules are perfect for a TDD approach. I recommend reading about the Review.Test module and the advice it gives.
I would not worry about autofixing this rule. If you do want to do that, I think you can only do it cleanly for simple cases. A few that I could see:
let-- usage of a literal tuple( a, b )=(1,2)inb-->let
Unsure about this one, but this is something that you could do.
let( a, b )= someValue
inb-->let-- Wrap with parens just in case. elm-format will remove it when possible
b =Tuple.second (someValue)inb
I don't see a clean way of doing it for more complex things, like the return type of a function. It's fine to let the user handle some of the issues. It's better to let the user handle fixing the problem rather than the tool resolve it in a partial, bad or questionable way.