MicrosoftA change this significant, and unintuitive, warrants some explanation as to the reasoning behind it I think. It stands to reason that if Azure AD Connect is synchronizing values from on-prem and they are unique there, then they would be unique in the cloud as well. Are you just trying to cut down on compute time for replication, or is there some kind of failure occurring regularly because the directory object is being renamed/moved with a change in CN?
Am I really going to start seeing that GUID twice in the output of Get-Mailbox, which by default shows Name and ExternalDirectoryObjectId? Could it have something else included instead (like DisplayName)?
Given that Name/CN is the output of some cmdlets (some already mentioned by others, and AcceptMessagesOnlyFrom comes to my mind from get-mailbox), it makes it very difficult (or at least inefficient, increasing the number of calls to the cloud to resolve EDOID to Alias, etc.) to locate an on-prem user from EXO PowerShell output since EDOID isn't written locally.
Hopefully the goofy mismatch between old and new accounts won't be visible to end-users (I don't believe it would be). But once Name goes read-only, I hope there aren't any Exchange admins out there who are divorced from an abusive spouse and just can't get rid of that remaining reference on their own account.
