No-op constructions like 'bytes("")' could help for older versions of Python, though. A very, very small runtime shim could provide support for these, if 2to3 could be told about it somehow.
You actually don't *need* 2to3 support for that - bytes("") can work in either version:
2.x: def bytes(s): return s
3.x: def bytes(s) return s.encode("ascii")
On top of that, you *could* as for bytes("") to be converted to b"" in 3.x - and it is indeed possible to tell 2to3 about that, and you don't even need to modify 2to3's source to do so: it can be part of your package.
Also, running 2to3 on installation is kind of annoying, as you get source that isn't itself the canonical source, so to fix bugs you have to look at the installed source and trace it back to the bug in the original source.
Given the way tracebacks are built, i.e. from filenames stored in .pycs rather than based on where the code was actually loaded in the filesystem, couldn't 2to3 could do .pyc rewriting to point at the original source? Sort of like our own version of the #line directive? :)
I think it could, but it would be fairly flaky as the pycs can get lost, and lose that information after regeneration. Also, it may be confusing in other scenarios.
I'd rather have it generate separate mapper files, and change the traceback printing to consider these (as an option).
Seriously though, I find it hard to believe that this is a big problem. The 3.x source looks pretty similar to the 2.x source, and it's good to look at both if you're dealing with a 3.x issue.
That's my experience as well - the only challenge is that you can't cut-n-paste the source URL into an editor.