Oleksii, that is correct - you should not see any duplicate users after upgrading to 3.0.1.

Given Confluence 2.7.3 with osuser/ldap integration, will it migrate to atlassian-user/ldap without username duplication and all the consequences of duplication if following the migration procedure described in documentation?

Unfortunately, this is not just cosmetic.
Administrators are no longer able to add or remove users from groups that were previously defined. This happens in the case where the user's pre-LDAP name matches is a valid LDAP name.

The reason this happens is that anytime you click on a user link (i.e. in the Group Members page or on either of the duplicated users) Confluence takes you to the View User page of the LDAP instance of the user. Changing this user's group membership does not affect the group membership since the pre-LDAP user is still a member of the group.

This particular bug represents the duplication of names in the UI. The inability to map groups between the users is reflected in CONF-10654. There's a utility attached to CONF-10654 that will merge the groups from the old user into the new (after which point you should be able to edit the groups).

Also, the old user cannot log on (only the LDAP user can), meaning the fact that the old user is in confluence-administrators will not get picked up.

For all - please open up a support ticket on http://support.atlassian.com if this isn't the case - you can ask for me or mention this bug report - and we'll work through any particularities.

We've implemented a fix whereby duplicate users are filtered out of the search results. Two users are considered duplicates if they have the same username.

This is better than purging the duplicate accounts since doing so will not solve the problem permanently since its entirely possible for a new LDAP users to be added with the same name as local users.

Jeremy,
Unfortunately, this is not just cosmetic.
Administrators are no longer able to add or remove users from groups that were previously defined. This happens in the case where the user's pre-LDAP name matches is a valid LDAP name.

The reason this happens is that anytime you click on a user link (i.e. in the Group Members page or on either of the duplicated users) Confluence takes you to the View User page of the LDAP instance of the user. Changing this user's group membership does not affect the group membership since the pre-LDAP user is still a member of the group.

This is a very big concern in the confluence-administrators group.

We migrated from local users to LDAP integration a couple years ago, and we've had duplicate users ever since. The work-around was to repopulate all of our group memberships (we still use local groups). The migration code was definitely b0rken back then, but even if it's fixed now, it don't think it helps me. What I'd love to see is a resolution to this request from 2005: CONF-4858 (which looks to be related to this issue).

PS: Ivan, the link you posted is inaccessible. I get a PERMISSION VIOLATION page.

Unfortunately I can't access the above link, and we now have this issue in production, without migration or initial creation of local users (for most users, at least), all come from LDAP/AD.
Our users are very confused by it.
Any ideas or workarounds (if only a display filter)?

https://support.atlassian.com/browse/CSP-29104

Would be greatly appreciated if we could please have an update as to when this issue can be addressed and what release it could be expected? We are looking to migrate to AD authentication in March and need to know if we will face this issue at that stage.

This issue is still unresolved at this point in time, although it is towards the top of our priority list for bugs to fix.