Minor smell cleanup - #8691

Purely academic, but: What is the rationale for using scoped_lock on single mutexes? As I understand it, performance-wise, lock_guard is the same for single mutexes but some consider scoped_lock to be less safe:

From Sonarscan:

std::scoped_lock basically provides the same feature as std::lock_guard, but is more generic: It can lock several mutexes at the same time, with a deadlock prevention mechanism (see S5524). The equivalent code to perform simultaneous locking with std::lock_guard is significantly more complex. Therefore, it is simpler to use std::scoped_lock all the time, even when locking only one mutex (there will be no performance impact).std::scoped_lock basically provides the same feature as std::lock_guard, but is more generic: It can lock several mutexes at the same time, with a deadlock prevention mechanism (see S5524). The equivalent code to perform simultaneous locking with std::lock_guard is significantly more complex. Therefore, it is simpler to use std::scoped_lock all the time, even when locking only one mutex (there will be no performance impact).

simpler to use std::scoped_lock all the time

Yes, I agree with this. What do you think about what Howard Hinnant is saying? He is saying that scoped_lock is less safe because you can accidentally lock 0 mutexes. TBH, I don't want to get bogged down in academic discussion, just curious about your perspective. From the reviewer's perspective: It's more work to review because I have to check that the mutex was passed to the lock in each code change, and there is a possibility that we missed one.