If email is to be used as user identifier, i feel that it should be unique.
And that, in my opinion, can be a more disrupting change than skipping on this feature...

Non unique email may have a use case for notification management, as different users may want to receive emails in a common inbox.
So maybe this could be solved by having a unique user email (used for authentication, password management, etc), and >0 non unique recipient emails, used for notifications.

Another view:
Having separate concepts for:

• system user, representing the person identification, as the agent, profile, and data within the application.
• account login, representing how the agent logs in the system.
  Account login may be user id+password, a uniqe email+password, openid, etc

If you look into what is common is that there is a single email per user that is used for notifications and authentication. In some cases, there may be aliases, but these are just used for scenarios like social networking scenarios like facebook and linkedin. Or in aliasing scenarios like github where users may want to claim ownership of multiple emails address to link such commits to their user account.

Note that even if we enforce uniqueness, there is also the possibility of using the + approach to have test accounts or two accounts that are necessary to point to same inbox.
myemail@mydomain.com
myemail+2@mydomain.com

If you think about scenarios we think about today. They are:

• Notifications
• Reset password

For notifications, it is OK for share, but for reset password, having a shared mailbox where such resets fall is kind of strange and breaks the identity concept associated with the user account that reset.

In order not to try to boil the ocean and to be paralyzed by the corner cases. We have two options:

1. Provide an option to enforce email uniqueness for newly created accounts within existing instances / new MantisBT installations (ideally ON by default). But can be set to OFF. People who do need it will know because of the error message will drive them to configure.
2. user_get_id_by_email() should have a predictable behavior when email is used multiple times, e.g. prefer enabled accounts over disabled, prefer higher access level over lower ones.
3. Enable login via email in general (leveraging criteria in 2), or at least if it is unique.

I don't see a downside for the above. I think it is an improvement over where we are at today.

Another option for point 2 above, is to have user_get_ids_by_email() that returns enabled accounts sorted by access level (DESC) and return the first one that matches the password.

As per 3, we can still decide to only make login via email work when we get a single email address back.

I am fine with the proposed approach, however I think we should allow admins to prevent the fallback to e-mail address identification if they don't want it (e.g. in my previous company, relying on a user ID that can't somehow be related to the user's name was a mandatory requirement from IT security, eg. M123456). I don't really care about the default setting for this.

if email were to be set unique, id say go straight into it and dont add a cofiguration to disable.

For a upgrade path, maybe:

• adding support for additional emails, I think this has been requested from time to time. It would allow using one or more separate email for notifications, which dont need to be unique, and would not serve for authentication purpose. (Note that probably wouldnt need to be searchable either).
• Upgrade can keep current emails that are unique, as main email. Non unique emails are moved to the prevously commented alternate email.
• A warning on user login that recommend to fill main email if its empty.

PR: https://github.com/mantisbt/mantisbt/pull/712