Bug Report: Escaped backslash incorrectly reinterpreted as control escape in double-quoted strings

Hello Zsh Development Team,

I'm reporting a bug in zsh's handling of escaped backslashes within double-quoted strings. When \\b appears in a double-quoted string, zsh incorrectly processes it as a backspace control character, even though the backslash has been properly escaped.

Environment

Zsh version: 5.9
Terminal: Ghostty
OS: Ubuntu 24.04
Comparison: This bug does NOT occur in bash - bash handles the same input correctly

Minimal Reproduction

The bug is clearly demonstrated by comparing two nearly identical commands:

echo "\`\\slog\\\`"

Expected output: `\slog\`
Actual output: `\slog\` ✓ (works correctly)

echo"\`\\blog\\\`"

Expected output: `\blog\`
Actual output: log\` ✗ (incorrect - backspace eats preceding characters)

Analysis

The sequence \\b should produce:

\\ → literal \ (escaped backslash)
b → literal b
Final result: \b (two literal characters)

Instead, zsh appears to:

Process \\ → literal \ ✓
Reprocess the literal \ combined with b as \b → backspace control character (0x08) ✗
The backspace then erases preceding text

This is a Parser Bug, Not a Builtin Issue

I've confirmed that both echo and printf exhibit identical behavior, proving this occurs during quote parsing before command execution:

printf "xyz \`\\blog\\\` \\n"
# Output: xyz log\`

echo printf "xyz \`\\slog\\\` \\n"
# Output: xyz `\slog\`

Both produce the same incorrect output, confirming the bug is in zsh's double-quote parser.

Inconsistent Behavior

The bug only affects certain characters:

Input	Expected	Actual
`\\s`	`\s`	`\s` ✓
`\\x`	`\x`	hex escape prefix ✗
`\\b`	`\b`	backspace control char ✗
`\\t`	`\t`	inserts a tab character✗
`\\n`	`\n`	inserts a new line ✗

The correctness of escaping depends on which character follows the escaped backslash, which violates fundamental escaping semantics.

Bash Comparison

The same commands work correctly in bash:

# In bash:
echo "\`\\blog\\\`"
# Output: `\blog\`  ✓ (correct)

Expected Behavior

Once a backslash has been escaped with \\, it should become literal and must not participate in further escape recognition. This is standard escaping behavior across all programming languages and shells.

Affected Use Cases

This bug affects:

Scripts outputting literal paths or strings containing \b, \a, \f, etc.
Data serialization and logging
Any code dynamically constructing strings with backslashes
Cross-shell compatibility

Technical Description

The bug appears to be a double-processing issue where zsh's escape processor runs after escape consumption in double-quoted strings, allowing already-escaped backslashes to trigger control escapes on a second pass when followed by specific characters that form C-style escape sequences.

I've attached screenshots demonstrating:

The \\slog vs \\blog comparison showing the inconsistency
Both echo and printf producing identical incorrect output, proving this is a parser issue

Please let me know if you need any additional information or test cases.

Thank you for maintaining zsh!

Best regards, Jelius