Change:
<del> {"$message_type":"future_incompat","future_incompat_report":[{"diagnostic":{"$message_type":"diagnostic","message":"unused variable: `x`","code":{"code":"unused_variables","explanation":null},"level":"warning","spans":[{"file_name":"$DIR/future-incompat-json-test.rs","byte_start":338,"byte_end":339,"line_start":9,"line_end":9,"column_start":9,"column_end":10,"is_primary":true,"text":[{"text":"    let x = 1;","highlight_start":9,"highlight_end":10}],"label":null,"suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"`-A unused-variables` implied by `-A unused`","code":null,"level":"note","spans":[],"children":[],"rendered":null},{"message":"to override `-A unused` add `#[allow(unused_variables)]`","code":null,"level":"help","spans":[],"children":[],"rendered":null},{"message":"if this is intentional, prefix it with an underscore","code":null,"level":"help","spans":[{"file_name":"$DIR/future-incompat-json-test.rs","byte_start":338,"byte_end":339,"line_start":9,"line_end":9,"column_start":9,"column_end":10,"is_primary":true,"text":[{"text":"    let x = 1;","highlight_start":9,"highlight_end":10}],"label":null,"suggested_replacement":"_x","suggestion_applicability":"MachineApplicable","expansion":null}],"children":[],"rendered":null}],"rendered":"warning: unused variable: `x` </del> <ins> {"$message_type":"future_incompat","future_incompat_report":[{"diagnostic":{"$message_type":"diagnostic","message":"unused variable: `x`","code":{"code":"unused_variables","explanation":null},"level":"warning","spans":[{"file_name":"$DIR/future-incompat-json-test.rs","byte_start":338,"byte_end":339,"line_start":9,"line_end":9,"column_start":9,"column_end":10,"is_primary":true,"text":[{"text":"    let x = 1;","highlight_start":9,"highlight_end":10}],"label":null,"suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"`-A unused-variables` implied by `-A unused`","code":null,"level":"note","spans":[],"children":[],"rendered":null},{"message":"to override `-A unused` add `#[allow(unused_variables)]`","code":null,"level":"help","spans":[],"children":[],"rendered":null},{"message":"if this is intentional, prefix it with an underscore","code":null,"level":"help","spans":[{"file_name":"$DIR/future-incompat-json-test.rs","byte_start":338,"byte_end":339,"line_start":9,"line_end":9,"column_start":9,"column_end":10,"is_primary":true,"text":[{"text":"    let x = 1;","highlight_start":9,"highlight_end":10}],"label":null,"suggested_replacement":"_x","suggestion_applicability":"MaybeIncorrect","expansion":null}],"children":[],"rendered":null}],"rendered":"warning: unused variable: `x` </ins> --> $DIR/future-incompat-json-test.rs:9:9 | LL |     let x = 1;

Discussion:
For example: I don't like that refactor because I might end up with local variables that do nothing. I think should just ignore unused local variables all together. If just renames local variables to hide the warnings from the compiler, then the compiler lint is a bit pointless. Renaming unused function parameters seems fine.
To get a better understanding of your thought process, why do you feel should treat local variables and function parameters differently here?
For example Now at one point you remove , and then cargo fix will rename to Now you have you might never find this in your code base. You really wanted to remove it, or maybe it was a bug in the first place that you are not using it anymore. Just renaming it for the sake of removing the warning seems wrong. Maybe it should also not rename parameters for free standing functions. I think that there are some cases in functions were you just want to rely on type inference and then the parameter should always be , but I think that decision should come from the programmer. It seems reasonable to rename parameters for trait impls because you can't just change the function signature, and you might not always want to use the parameter.
I think I'm persuaded? Here's where the lint is issued: We just need to change to to tell not to auto-apply the suggestion. We have access to the HIR here, so setting the applicability conditionally based on whether it's a binding or a method argument should be doable, although potentially slightly tricky.
I think you are right, this is misleading in your use case. Just wondering: At which points in your workflow are you running cargo fix? I also think this is one of the cases where we need to differentiate between "cargo fix should fix it" and "get a lightbulb with auto-fix suggestions in your editor". Just because it might be auto-fixable doesn't mean we should automatically fix it. This is a discussion for a higher level issue, though.
I only ran once for a project where I had a few warnings after I did some refactoring.
Is anyone against changing this suggestion to simply be instead of ? Prepending an underscore to variable names is saying to the compiler "yes, I intentionally won't use this value", which should very much be a manual action. I'm hesitant to use , since it might silently hide a bunch of leftover variables from an in-process refactoring. I mostly want it to remove unnecessary parenthesis and fix my imports, this is overreaching a bit.