As others have stated, if you can provide an implementation than please do so, as that will help understand some of the technical details of what you are doing and if it is sound.
For example, on page 3 section "Detailed Semantics" line "Direct construction" it says that it calls lock() on all mutexes using a deadlock avoidance algorithm. The concept isn't unsound but if you took that on its face value "just call lock()" you wouldn't be able to avoid a deadlock, I assume it is meant to be something more like in the description of std::lock: https://en.cppreference.com/w/cpp/thread/lock.html

Also mention pros/cons over std::lock.

I would also like to see an example use case to better understand in what scenario I would want to use this.
You should also discuss other alternatives, like expanding the capabilities of the existing locks (since you provided a table comparing them) instead of creating a new thing.

I'm not entirely sold on the name "unique" "multi", unique_lock naming was best understood in the context of shared_lock and this is not that (I think, does it support shared locks?). Perhaps you want to explore some alternative naming.

Br,
Tiago



________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Ted Lyngmo via Std-Proposals <std-proposals_at_[hidden]>
Sent: Sunday, September 7, 2025 1:18:05 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Ted Lyngmo <ted_at_[hidden]>
Subject: [std-proposals] P3833R0a - std::unique_multilock

Here's my first version of a proposal to add std::unique_multilock and
I'd be glad if I could get some feedback on it.

I'm not sure if it's needed but I could add a reference implementation
to it too. Should I?

Best regards,
Ted Lyngmo