Employ 'user' alias rather than 'user/%' alias for logged-in user

I was wondering the negative impacts of forgetting to re-insert the statement in file include/path.inc. Is there any chance of it breaking the site permanently or hurting the database in any way?

There is zero chance of breaking the site or the database. Extended path aliases does not write to the database.
If you upgrade to 6.16 (which will obliterate that statement you put in for 6.15) and you forget to put that statement back in, all that will happen is that part of the extended path aliases functionality no longer works, namely the option (if used) where you specify on which pages blocks should be visible, using aliases and wildcards.

Oh and by the way, should you decide to disable and uninstall Extended Path Aliases, you do not have to undo the change, as the statement checks whether the module is installed and will auto-revert to default core behaviour if it isn't installed.

Regarding the mapping... it seems a bit odd (and in fact unusable) to map different user ids to the same URL. How will Drupal know which user you mean when a link is clicked that points to "www.mysite.com/account" -- it needs to be a one-to-one mapping... no?

By creating aliases at Administer >> Site building >> URL aliases you can realise the first and third of each of the two sets of URLs mentioned in comment #2.

1) alias "account" for "user"
2) alias "account/name_or_id" for "user/%" (you can have this generated automatically for all users when you install the PathAuto module)

Your second request, "(my)account/edit" will have to become account/%/edit, I think (with % being the logged-in user id).

Basically you're asking for the alias system to work differently rather than extending it. This is outside the scope of Extended Path Aliases.

I had another look at this and was able to implement the feature requested in #2.

Checked into the repository as the dev version.

After downloading, please make sure to follow these steps:

Create the following aliases at Administer >> Site building >> URL aliase:
1) alias "account" for system path "user"
2) aliases "account/user-name" for system paths "user/%", where % is the user id
(you can have this generated automatically for all users when you also install the PathAuto module)

After this the system should behave as requested in the bottom part of #2.

Enjoy!

Please test and let us know if this works as intended before I make this an official release.

But isn't that what this latest dev version ($Id: path_alias_xt.module v 1.7 2010/09/23 04:45:05) does?

If you keep the "profile/[uid]" alias (for "user/[uid]") and then add one more alias, "account" for "user", then this version will do what you describe. Or am I misunderstanding you?
The alias for "user" (if defined) has higher priority for the logged-in user than the alias for "user/[uid]".

BTW isn't it nicer to use "profile/[user-raw]" instead of "profile/[uid]", so that you get to see the user's name rather than their number?

Note, for others reading this, with Pathauto enabled, you can bulk-delete the existing ones via the "Delete aliases" tab under Site building >> URL aliases before bulk-assigning the new replacement string under "Automated alias settings".

I'm re-opening this because I have found a case where this behavior does break something...

I have a block that is cached per page (and not per user) and contains a link to a user account. Now, if the first user who generates this block happens to be the one that is being linked to, the link is changed to "/user" and that's the way it get's then displayed to everybody.

I also have to say that I don't like this method, as it's basically a hack. If an element really wants to display a link to the current user account, it should do so explicitly. If it doesn't, then this decision should also be respected.

Please at least implement an option to turn this substitution off.

Hmmm..... I think I see what you are saying Ralf....
Config option may be the way to go....

Turned into a configurable option as suggested in #9.
Better late than never.