When a username is selected other than the default, then returning to the username changer:
Return to the epilogue. The username is now the one selected.

Select the username again.
Notice the default username is checked, and is shown as the current username in the top description.

Select the default username.

@folletto - fixing this bug was rather simple. However, it presented another issue. When the username changer is launched, the suggestions are based on what the username _is_, not what it _was_. Therefore, if you select a username and return to the username changer, the default username is no longer shown in the list.
Ex:
Questions:
cc: @elibud
If you search for the original username can you still get it?
Is this acceptable?
Yes.
@elibud , @folletto -
If you search for the original username can you still get it?
Well, I thought so. I guess I was blind. I just tried again, and it turns out - No. 馃槥
Guess: it's because at creation it gets reserved, as such the API can't return it as available.
So: it would be nice if the client stores the old one, and keeps it always in the list, regardless of other choices (and simply doesn't do the API call if the user went back to it).
That said, I think it's not a major issue and we can ship without if needed.
@folletto -
it would be nice if the client stores the old one, and keeps it always in the list, regardless of other choices (and simply doesn't do the API call if the user went back to it).
Agreed. I'll create a new issue for that. Thanks!
cc: @elibud
@ScoutHarris at that point is the account already created? can we authenticate the suggestion call to get the original name?
Just to make a note - as @elibud and I discussed, fetching username suggestions is authenticated. We would expect the endpoint to return the reserved username when searched for. A p2 post will be made!
Fixed with #8867