I think there's nothing to be done for a bug this general.

If you find a specific object whose repr() is awkward, go ahead and file a specific bug.

In most cases I think people who parse repr() output know they are on thin ice, and would prefer that the object whose repr() they are parsing had a method or attribute that returned what they were after.  Example: in 3.2, parsing repr(range(...)) is the only way to access the start/stop/step attributes; but we're fixing this for 3.3.  Exception: unittests that specifically verify the form of a repr().

Off-topic: I sometimes wish that the str() of a class would return the class name rather than its repr(); that way "print(str)" would print "str" instead of <class 'str'>.  (Use case: printing an exception and its message: I wish I could print("%s: %s" % (err.__class__, err)) instead of having to use err.__class__.__name__.)  One could even claim that the repr() of a class could be the same, since one of the guiding principles for repr() is that it should, if possible, return an expression that (perhaps given a suitable environment) could reconstruct the value exactly (and otherwise it should have the <...> form discussed in this issue).  But both of these wishes are debatable, and if anyone cares, they should open a new bug to discuss it.