At least on Darwin platforms and on Linux, the implementation does trap at runtime if you try to recursively attempt to acquire the lock. Windows isn't too specific, but does specify that:
Exclusive mode SRW locks cannot be acquired recursively. If a thread tries to acquire a lock that it already holds, that attempt will fail (for TryAcquireSRWLockExclusive) or deadlock (for AcquireSRWLockExclusive)
Enforcing that all platforms trap in the implementation would require extra storage overhead on top of the platform mutex + value as well as runtime overhead. Currently the API documentation (in the proposal) states that:
/// - Warning: Recursive calls to
withLockwithin the
/// closure parameter has behavior that is platform dependent.
/// Some platforms may choose to panic the process, deadlock,
/// or leave this behavior unspecified.