Things which are trickier than necessary to handle at the moment without these codes:
- Differentiating between certain "UI" responses. For example - distinguishing between a clientlogin UI response indicating a temporary password needs to be changed vs a clientlogin UI response indicating the user should update their pwd of fewer than 8 characters when logging in for the first time after being granted admin rights. Presently the only differentiator in the response is the error message itself, which is problematic for apps because these messages sometimes refer to UI elements which may or may not be present in app interfaces ("Skip" buttons etc - sometimes for size constraint and localization reasons icon are used instead).
- Differentiating between certain "FAIL" responses. For example - distinguishing when a login has failed because the user's repeated failed login attempts have triggered a captcha requirement. Less state would have to be managed if you could just check the clientlogin UI response for a "NeedsCaptcha" code and only *then* make a secondary "authmanagerinfo amirequestsfor login" query to fetch captchaID/URL.
- Determining what field should receive focus during login or account creation. For example, during account creation if the user chooses a user name which already exists it would be nice to move focus to the username field when showing them that message. Similar issues exist around setting focus on the captcha field.
- Determining when login or account creation have reached the state where the user has fulfilled all non-captcha requirements. For example: during account creation we may want to hide all the captcha interface bits until the user has chosen a valid user name, etc.