Hi,
[small rant before I dive into the mud]
If your usernames are not unique across different contexts, then they are not usernames. You may pretend they are , but you are lying to yourself (and probably to your users
).
A username is (must be) unique inside what I will call and "authentication boundary". An authentication boundary determines (among other things) who is authoritative to perform the authentication, what is the set of different identities that can authenticated (users, machines, etc.) and how to authenticate them .
If your authentication boundary is "this Moodle site", then you need unique usernames in mdl_user. That's why we have a constraint on (mnethostid,username) on that table. If your authentication boundary is "that LDAPserver", then you need unique usernames accross all your LDAP contexts (for that server!). If your authentication boundary is "that context on that LDAP server", then you need unique usernames inside that particular context, but not accross all contexts on that LDAP server.
[/small rant]
Right now we have a single authentication boundary: "this Moodle site". This makes many things simpler, but limits ourselves in cases like the one you describe.
To be honest, I don't like your prefix implementation It fixes the symptoms (all?, some?), but not the underlying problem. And I have the feeling that it will come back to bite us in the future (when some other corner cases and interactions with other parts of Moodle appear).
I know your proposal is smaller, faster to implement and more self-contained than the "Real Fix (Tm)". And that weighs in a lot when you are the one implementing it (as opposed to telling others how they should do it )
But somehow I feel that if we are going to break change how things works, we should try to come up with a proposal that addresses the underlying problem: usernames are only unique inside "authentication boundaries". And that includes internal authentication plugins (manual, email, etc.) and external authentication plugins (LDAP, DB, CAS, etc.)
So I think we need to reflect that fact in our proposal. If there can be more than one authentication boundary for any authentication plugin, then we need to treat each authentication boundary as a separate entity. E.g, there is only one authentication boundary for 'manual' auth plugin, but there could be several authentication boundaries for the 'ldap' plugin (your initial problem).
Where am I heading with all this bla-bla-bla? Multi-instance authentication plugins. Each authentication boundary is represented by a different authentication instance of the right type. And make the constraint in mdl_user be (mnethostid, username, authinstance).
Have multiple authentication boundaries in your LDAP server? Create multiple instances of the LDAP auth plugin and configure each one with the details needed for that authentication boundary. By the way, this is a special case of the multiple LDAP servers that several people are struggling with since a long time ago
Of course, you still need to change the auth API so that active modules can "inject" form elements to the login form, so users can specify which authentication boundary they belong to (remember we can't get this info from the mdl_user table like we do now in subsequent logins, as usernames would no longer be unique in that table).
I know this is a big, scary change. But I have a gut feeling that it will pay back in the long run.
Still, I don't have the time to implement any of this, so this is cheap talk and I won't show you the code . So feel free to ignore all of this
Saludos. Iñaki.