@not-an-aardvark, thanks for your PR! By analyzing the annotation information on this pull request, we identified @pmcelhaney, @vitorbal and @platinumazure to be potential reviewers

LGTM

I'm not sure we should have a fixer for this rule. Most of the time, when someone is asking in chat about why the rule reported a particular character sequence, it turns out they were intending to have a backslash literal all along, so the correct fix was to double up the backslashes.

I don't think we can know with certainty what the user's intent was (\\: vs :), so I am 👎 to including autofix on this rule.

@platinumazure Note that there are already a lot of existing fixers that do things like this. For example, indent will fix this:

if (condition)
  doTheFirstThing();
  doTheSecondThing();

...to this:

if (condition)
  doTheFirstThing();
doTheSecondThing();

...which is semantically the same, even though the user might have intended to do this:

if (condition) {
  doTheFirstThing();
  doTheSecondThing();
}

Thank you for this PR!

I had thought the fixing is very clear until I read @platinumazure 's comment.

Granted, there are issues about that: #5831, #6148, #6514, #6842
Their intentions were \\, and no-useless-escape helped them to fix the bug.

Personally, I like this fixing. 😟

Sorry, but I'm not convinced fixing is a good idea here. The reason is because, as far as I can tell, it's almost 50/50 whether the correct fix is to add an extra backslash, or to remove the existing backslash and use the unescaped character. I don't think that's something we can predict with any accuracy.

If someone can convince me of how we can reliably predict what the correct fix is for a given report, I'll reconsider. But until then, I remain opposed.

I'm inclined to agree with @platinumazure that the correct fix in this case isn't always obvious, so it would be best not to try to fix it.

As this has already been open for a month and there's some 👎s here, I'm closing.