Ability to set nicknames equal to usernames

[prryplatypus]

Description
Save/set nickname on guild members even when username is exactly the same.

Why This is Needed
Currently the behaviour when trying to set a nickname that's the same as the username the API responds with an OK code, making it apparent that the nickname has been set. Unfortunately, if the username is equal to the nickname then it is not set, and if the user changes their username, so does their display name in the guild. It also seems pretty inconsistent that the nickname is not set when the username is the same, but that if the username is changed to match the nickname, then the nickname remains set.

Currently the only way to work around this is by listening for PRESENCE_UPDATE events, and crosschecking on each of them, but this doesn't work for our specific usecase. In our platform, users request one of 3 available nicknames when joining a server using the guilds.join scope. When they make a choice, the action is simply performed and their preference is not stored anywhere, so it is not possible to check what they selected when an update event happens.

Alternatives Considered

• Maintaining a persistent connection to the gateway and messaging the member to update their nickname each time an update event was triggered, if they have no nickname set.
• Storing their preference for each of the guilds and hammering our database with every PRESENCE_UPDATE event.

Additional Details
This was apparently already spoken about in #667, but it did not seem to take into consideration usecases where there is several nicknames possible for the user to choose from and/or which don't store this data and/or which only react to user-initiated events.

[ckohen]

Something I'd like to mention is that you can already have a nickname the same as username, but its a rare occurrence. This occurs when you have a nickname set on a server, then change your username to that nickname. I experienced this on a server where I didn't have change nickname perms, but I don't think that has to do with it.

[advaith1]

I prefer (and rely on) the current behavior; maybe a "force" option could be added instead of changing the normal behavior?

[ckohen]

Whats the use case for this over setting null?