Node edit form risks deleting another node's path alias

Report type:
'happened to notice it'
So, noone is going to set RTBC for needing the patch.
However, if someone ever happens to encounter this exotic problem, they will not be able to trace this => it's best off committed.

Issue:
path_form_alter, for node edit forms, sets $form['path']['pid'] to remember which path alias to overwrite on submit.
It doesn't actually check whether the path belongs to the node currently being edited! So on submit, we could be overwriting (deleting) some other node's path.

Cause:
On March 1st (and March 4th in Drupal 6.16), #358315 was committed, which effectively removes all constraints on the url_alias table. Now it is possible to have multiple occurrences of the same dst/language pair in the 'url_alias' table. Before this commit, it would be implicit that path_form_alter always retrieved path information for the correct node.

See http://drupal.org/node/358315#comment-1225869 #4 - #7 for the change. It seems this was done inadvertently. People added a column to a unique index for speed reasons - but failed to take into account that 'unique indexes' also double as 'constraints'. The uniqueness constraint for alias/language pairs is gone now.
...at least, this removing of the constraint seems inadvertent, because it is not discussed anywhere. (Not in #358315 anyway.)

Mitigating factors:
- the node edit form. and pathauto_create_alias(), both check for an existing alias in the url_alias table. So the only way for a duplicate dst/language pair to end up in the 'url_alias' table, is for contrib code to call path_set_alias() with an 'alias' argument that already exists for another 'path'. Or to change $node->path to an existing node's path and then call node_save().
- drupal_lookup_path() always sorts by 'pid DESC' when looking up paths/aliases, so duplicate aliases in the 'url_alias' table do not cause unpredictable behavior. (Note that this did introduce a behavior change in D6.16: in D6.15 if a node tries to register a duplicate path alias, this will generate an SQL error - and in D6.16, the node will silently become the 'effective owner' of the alias.)

This is why I doubt whether regarding the absence of the constraint should be considered a bug in itself. I don't feel qualified to judge this (and it's too much work :p) - feel free to take this up elsewhere.

Why reported for D6:
In D7, path_form_node_form_alter() retrieves the path information by 'src' (source path), instead of by 'dst' (alias). So the problem doesn't exist there.

( system_update_6055 dst_language dst_language_pid <- keywords for search engines :) )