I'm not sure what the OP wants to achieve with the post (simply express anger, or suggest this should be changed in an upcoming release(?)), but I guess the idea is that '\\' (or q{\\}) would mean two backslashes — i.e. you simply cannot escape the delimiter, which means you'd just have to choose a different delimiter (using q) in those cases.

Typical pitfall with the current workings is that you tend to forget to escape the double backslashes in UNC paths, such as

my $dir = q{\\\\dfsshare\foo\bar};
            ^ ^
[download]

IMHO it's impossible to disable "escaping" and allowing arbitrary character sequences.

I mean by using an alternate delimiter like q{} or q// the problem is just postponed.

  DB<105> print q{\}}
}
[download]

Then the only possibility left would be concatenating with a constant representing the delimiter:

 eval( '$string=' . QUOTE . 'abc' . QUOTE );

instead of  eval( '$string=\'abc\'' );

Possible ... but desirable?

Cheers Rolf

UPDATE: or eval( '$string=' . q{'} . 'abc' . q{'} );

by using an alternate delimiter like q{} or q// the problem is just postponed

Postponed until when — the unlikely event that all possible delimiters also do occur within the string itself?

For most practical purposes, this likely wouldn't be an issue (or less of an issue that having to remember to take care of the special cases \\ and \<DELIMITER>).  And in those remaining few cases, you could still resort to concatenation, as you're saying.

But why write silly things like '$string=' . q{'} . '}' . q{'} as long as can simply say q|$string='}'| ?

That said, I personally don't really have problems with the way it's implemented currently.