If I'm remembering the discussion I read correctly, what the parser does is to parse the a regular string and a raw string in exactly the same way, but in the raw string case, it does not do the subsequent escape sequence replacement pass on the parsed string.  This means that it follows the "escape the quote" rule when *parsing* the string, but does not do the subsequent post-processing that would remove the \.  But because the quote-escape has a consequence at the parsing stage, it applies to both raw strings and regular strings.  Which means that an odd number of backslashes cannot appear at the end of either type of string.  And as far as I can see there is no way to fix that, since otherwise the parser can't identify the end of the string.

Therefore if no escaping is done you do, as you say, limit yourself to not being able to put both ' and " characters inside a more-raw string.  This would break regular expressions, since exactly this case does occur when using regular expressions extensively.  And a trailing backslash would never appear in a regular expression.

So, clearly raw strings are optimized for regular expression use, and not for Windows pathname use.  The proposed 'windows raw string' literal would be optimized the other way.  Adding such a literal  is python-ideas territory.

Note that windows paths can be spelled with / characters, so this specialized use case has an easy workaround, with the added advantage that a repr of such a string won't appear to have doubled \s (which I always find confusing when debugging programs involving windows path names that use the \ separator).