So is it fair to summarise this as that all the Sendable conformances on this method are based on the assumption that you will be returning the lock state from this method, and the lock state itself is not explicitly marked as Sendable? And if you do not return the state, but instead just modify it, then it is safe to just use withLockUnchecked?

And, by extension, IF the lock state was required to be Sendable, then we would not need any Sendable conformances on withLock() at all? (But the usefulness of OSAllocatedUnfairLock would be slightly diminished, of course.)

No, that much is clear, my question here is, WHY is withLock marking its closure as @Sendable, since it should be executed synchronously in the same actor context? Your last point seems to support what I asked: It's marked as @Sendable because the state is NOT marked as Sendable. If the state was marked as Sendable, then the closure would not need to be @Sendable, because the Sendable conformance on the state would protect it. It seems to me that the correct solution here would have been to mark State as Sendable instead, but I assume this was not done because you might want to protect a type that did not have an explicit Sendable conformance yet, so instead this quite confusing @Sendable conformance was added to other parts of the API? But also, if so, why would the variation of withLock() that is available when State is Void be marked as @Sendable? This conformance means that OSAllocatedUnfairLock can not conform to NSLocking, which it otherwise could, and since there is no state there should be no need for this unexpected @Sendable conformance, right?

I have this issue, in the case where I get a userInfo dictionary from an OS API which is [String: Any], and I need to store it as a [String: any Sendable] to be able to fit it into my own code which is Sendable. What to do in this case?