Forced Password Change enforced on REST Services call - should it? and how not to?

What happens when an API and an API client, who have been getting along great for years, are successfully interacting on assumptions and a Force Password Change comes along one day? Something like this, that's what:

 12729789  28/Apr 14:37  warning   access denied  node/1584478
 12729790  28/Apr 14:37  warning   access denied  user/91/edit
 12729791  28/Apr 14:37  warning   access denied  user/91/edit
 12729792  28/Apr 14:37  warning   access denied  user/91/edit
 12729793  28/Apr 14:37  warning   access denied  user/91/edit

..and all user/91/edit requests are actually something like:
https://www.example.com/user/10490/edit?destination=services/session/token
That's because:

1. New user with default Force Password Change set
2. New user signs in not to the Drupal web UI but to Desktop via Services REST API
3. Client application /assumes/ the REST API services/session/token route would be satisfied
4. Client application /assumes/ the following /node/1584478 route would be satisfied
5. And Client application doesn't care than the previous requests got HTML back and /assumes/ that all the other routes would be satisfied as well

In a nutshell, when the API is hit by a user with Force Password Change pending, rather than the API either ignoring it or having a chance to return a 403 or something in json, Drupal instead redirects the menu routed request from Services REST API endpoint to Drupal page callback from the Force Password Change module.

I've not looked into how to address it yet, but I wanted to post it here in case it's interesting and you have some ideas.

PS: Thanks for the pseudo-mention in #2855070: Allow Drush One-Time Logins to Skip Forced Password Change (Drush Integration) → ;)