Rudder

So, the problem is that bash (or shell) replace \\ into \ and so the value reported by cfengine is the one with only one \. There is no simple way to change that appart from having a special case in expected report when we deal with command execution.

This does not breaks anything but impact compliance, so I put it in "misleading", but perhaps it more grave than what I understand now.

Setting it to critical, as it may lead to major outage (and executing commands is a main use case for rudder)

I had a similar issue recently, in a 6.2.9, if I create a technique via the technique editor using the File lines present method and want to ensure that the line \\"x is present, the technique editor does accept the input, but the generation will break with the following error:

⇨ Policy update error for process '8' at 2021-08-27 09:50:16 
⇨  Cannot write nodes configuration 
⇨  Unexpected: Error when executing hooks:
 Exit code=1 for hook: '/opt/rudder/etc/hooks.d/policy-generation-node-ready/10-cf-promise-check'. [stdout:   error: There are syntax errors in policy files
][stderr:/var/rudder/cfengine-community/inputs.new/testing/1.0/technique.cf:13:109: error: syntax error
    "File lines present_${report_data.directive_id}_0" usebundle => file_lines_present("/tmp/my_file", "\\"x"),                                                                                       ...] (for node(s) root)

The json escape it like such:

{
  "name":"lines",
  "value":"\\\\\"x" 
}

And in the cf file: file_lines_present("/tmp/my_file", "\\"x")

While in 7.0, it works perfectly. The same technique done via the technique editor does not break at generation time, and render the proper string in the target file.
Json generated by the technique editor was:

{
  "name":"lines",
  "value":"\\\\\"x" 
}

And the cf file:
"61986e26-f5d9-429b-8ffa-3cffb9befc72" usebundle => file_lines_present("/tmp/my_file", "\\\\\"x");

While the 7.0 took the exact same string as written in the json, the 6.2 seems to interpret the json while reading it somehow.

It's corrected in 7.0, and as explained won't be corrected in 6.x.