Since the time of its introduction in 2.6, a call to multiprocessing.Lock.release on an already unlocked lock resulted in behavior that did not match that of threading.Lock.release (which raised a thread.error as far back as 2.4 and probably longer than that historically).  Similar can be said of the RLock analogs.

This is but one discrepancy of many as described in issue23484.  Behavior in threading's locks going back as far as 2.2 has not been / is not matched in multiprocessing's locks since its arrival -- it does not appear to be a case of recent changes opening a rift between these two modules' locks' behavior.

Changing the behavior that has existed in multiprocessing's locks since its arrival in the stdlib would break existing code which depends upon it (as referenced in msg236431) so I will propose a patch for issue23484 to move ahead with correcting the documentation to describe the established behaviors of multiprocessing's locks -- as part of that proposed documentation change, the behaviors discussed here should also be covered.