I noticed a limitation in eZ Publish 4.7 ezurlalias_ml database tables. Because the tables primary key is created by combining the parent and md5 text it creates a problem in the following situation.

Our customer has a multi-language installation and in it, he has a media service node. Under this he has Videos etc.

http://customer.com/Media/
http://customer.fr/Media/
http://customer.com/Media/Videos
http://customer.fr/Media/Videos

Now the customer LATER starts to translate the pages names according to the languages conventions:
http://customer.com/Media/videos
http://customer.fr/Presse-Videos/Videos

Normally this would cause the url history to redirect users from http://customer.fr/Media to the new http://customer.fr/Presse-Videos.

This however for some reason doesn't happen. After researching I think the cause for this is the database table structure. Primary keys seems to be created based on parent+md5 (might have been id instead of parent, but same problem still occurs).

Lets say that the parent (or ID) is 5476 and the MD5 created from Media text is: h5583c

In database this means that http://customer.com/Media
would be Primary key: 5476-h5583c

And this http://customer.fr/Presse-Videos
would be Primary key: 5476-8273hdd

Problem is that this http://customer.fr/Media
would be Primary key: 5476-h5583c

The only differences each row has are the actions they take (often identical), the text (assumed to be always unique) and the lang_mask (probably language ID). In this case, all these types of rows share the same ID and parent because most often they are the one and same node.

This means that if a languages url is ABC no other language can have the same with a different action.

The solution would be, that the primary key would also include the language mask. This way you could have:

http://customer.com/Media/videos
http://customer.fr/Presse-Videos/Videos
http://customer.fr/Media/Videos

with no problems because the url's name uniqueness would be only required per language.

This problem can be fixed from the server redirecting and also, can be fixed by setting english as a secondary language, but this works poorly because we don't always want these types of situations to work:

http://customer.fr/about/ instead we want only the
http://customer.fr/sur/ to work.