À ce sujet, l'expérience de Python est instructive.

Dans Python 2, il y a deux types de chaînes
"toto" => type("toto") == str
u"toto" => type(u"toto") == unicode

Le premier ne peut contenir que des caractères ASCII, ce sont en fait des tableaux d'octets.
Le second représente une chaîne unicode, qu'il faut encoder (par exemple en UTF-8) pour avoir un tableau d'octets.
type(u"toto".encode(u'utf-8')) == str
type("toto".decode(u'utf-8')) == unicode

Idéalement, il faudrait toujours utiliser u"toto" quand on utilise du texte. Mais en pratique, on oublie le préfixe u, sauf quand il y a des accents.
u"toto" + "titi" fonctionne (concaténation), tout comme "titi" + u"toto" . Par contre, "titi" + u"tête" ne passe pas (il sait convertir de façon transparente une chaîne ASCII valide en unicode, mais pas encoder à la voler vu qu'il ne saurait pas quel encodage utiliser).

Au final, il y a beaucoup de bugs liés à ça, qui ne sont déterminés que quand on utilise des caractères accentués...


En Python 3, ils ont pris le taureau par les cornes, et ils ont corrigé cet (énorme, à mes yeux) problème de conception.
b"toto" représente un tableau d'octets
"toto" représente une chaîne de caractères unicode, et la concaténation ne fonctionne plus du tout entre les deux.
Du coup, on repère les bugs immédiatement.

Au final, il est assez difficile d'avoir des bugs d'encodage en Python 3, alors qu'il est très facile d'en avoir en Python 2. Bref, ça montre bien que la tentative du passage transparent de l'ASCII à l'Unicode a été catastrophique, et je pense que tout le monde est d'accord pour dire que c'est *LE* souci de Python 2.