look, I've tried to accomodate you but I'm getting tired of arguing with you.

That comment was before .NET 2, before support for LDAP. If we were setting the auth cookie I'd have gone along with allowing email and ldap together but I'm not changing that now.

If it is still important for userid to not be the same (I'm not so sure it is, they each must be unique per site but I don't see a big reason why they cannot be the same value for a given user) I would implement it different today perhaps with a custom validator on the registration page, but that would not solve the problem you are trying to solve for your 30 or so users that need to login without ldap using their email address. How about update their user ids to their email address and move on? Why must you keep arguing with me?

I'm arguing with you because I'm told to replicate the e-mail in two different fields under user profile as a "solution" to my problem when it really isn't. The user IDs for those 35 users were taken out of our donors database and we need those user IDs because of a module I'm working on which would use that database.

You could solve that problem in your feature by using a custom table to relate those ids.

I understand that you don't manually set the authorization cookie and that you let ASP.NET security framework take care of that, but I also know that this can be addressed and I'm willing to help.
I think the biggest issue here is that even though this is an open source product, the actual development of the entire CMS is fairly closed in the sense that it's not common practice for people to fork, make changes, and make pull requests. So essentially, one has to either fork the project and maintain his/her own fork, continually merging your changes into the fork or try and convince you first to avoid a situation where changes have been made, but you won't commit them.

You have a mythological view that all open source projects should be or are run a particular way. I'm not going to defend myself against that, I run this project my way, it is tightly controlled and that is my perogative, I've always been clear about that, I've never said its open for any or all changes to get in. I accept changes that I'm willing to accept or I reject proposals for many reasons that make sense to me. I'm not willing to make this change at this time. I'm sorry if you don't like that. Open  Source is many things to many people, an open source license doesn't mean every open source project must follow a particular process or that I'm doing it wrong if I don't accept your changes.

user ID and e-mail have separate fields for a reason. My original plan was to utilize as much of mojoPortal as possible and user ID and e-mail seemed to fit the purpose perfectly and they still do, but it looks like I'll have to work around the limitations.

They both serve the purpose of supporting authentication, neither one is an ID in the database sense of the word, they are not intended for joins to other tables in custom features, relating to other tables would be better implemented using UserID field or UserGuid field, but my guess is you do have the email in your external database so you could probably use that if you really wanted to, but a more correct relational way of doing it would use the actual ID fields as opposed to the loginname which is just labelled as User ID in the UI for the benefit of the user.

In a perfect utopian world maybe someday I would just sit around and coordinate the contribution efforts of others (if I agreed with the proposed changes in the first place), but in the real world that takes a lot of time reviewing changes and communicating back and forth and it makes the project require more formal processes the more developers that are involved, and that slows things down. And the more people who want to sling code my way it diverts my efforts off of my own devlopment agenda and puts it on someone else's. I have limited bandwidth so I run the project the best I can under the varying concerns and goals I have foremost of which is making a living. Have you ever heard of Rainbow portal? I once was involved with that and it was so open there were lots of people with commit access all coding in different directions and it ultimately self imploded as a project because there was no-one in charge enough to say no. If others run their projects differently that is up to them and not my concern to compete with them on process of running the project. I'm happy with the rate at which mojoPortal popularity is growing and I'm happy with the way it is progressing as a product, as far as I'm concerned my way of managing it is working very well.