Steven,

   I see how this can be a problem for you, but the provider model isn't
completely at fault here, I believe.

   The MembershipProvider doesn't account for a change in the username of
the user, which is why everything is keyed on that.  While you can perform
insert/update/delete operations on users, the one thing that you can't
change is the username (The UserName property on the MembershipUser is read
only).

   So, it stands to reason that if you perform a rename in AD, you are
doing it outside of the context of the MembershipProvider, and
unfortunately, it would be up to you to relocate profile information for any
accounts that you changed the name of (since this is not an operation that
is supported outside of the membership provider).

   Now, the part that I feel is at fault is the ProfileProvider, as it only
performs searches based on user names.  It assumes that the unique,
unchanging identifier for the user is the username, which can be argued
whether or not it is correct or not.  It can be argued that it is incorrect
because the MembershipUser class has a ProviderUserKey, (which in the case
of AD, probably returns the GUID of the user) which is also read only.

   Regardless, it's unfortunate, because you are dealing with a membership
provider which provides the action of renaming the user (while maintaining
the identiy) outside of the MembershipProvider.  Because of this, you will
have to keep track of when a rename is performed through AD and then update
your data store for the settings accordingly.