When a subsequent requestPointerLock is rejected, should an already locked target exit lock state?

[alvinjiooo]

In the PR #49's algorithm of requestPointerLock is currently missing the description for the scenario:
When a subsequent request failed (for any possible reason), should an already locked target exit lock state?

[scheib]

My opinion is no, lock should not be exited due to a new request that can not be satisfied.

E.g. Attempting an upgrade from a default request to a request with unadjusted movement that can not be satisfied should not cause the earlier lock to be exited.