multi_lock seems good enough imo, but you shouldn't get to hung up on it.
You put in a section discussing naming alternatives and then gives some pros and cons of each and give a reasoning why you picked the one that you did.
If someone doesn't like it they can bring it up for discussion, and you can ask for a vote between alternative names.
If a different name is picked you just change it in the next version of the paper, no big deal, it's normal for papers to change in this way.
The name itself does not change the core idea of the proposal, so most of the paper should be unaffected by this small detail.



________________________________
From: Ted Lyngmo <ted_at_[hidden]>
Sent: Wednesday, October 1, 2025 8:59:56 PM
To: Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] P3833R0a - std::unique_multilock or std::multi_lock

2025-09-10 17:38, Ted Lyngmo:
> 2025-09-08 08:06, Tiago Freire:
> >
> > multi_lock?
>
> Not bad! I could absolutely live with that name!

I've thought about the proposals for a good name a lot and I think
Tiago's is the one I like the most.

    one mutex 0-many mutexes description
+---------------+---------------+-----------------+
| lock_guard | scoped_lock | always owning |
+---------------+---------------+-----------------+
| unique_lock | multi_lock | (*) |
+---------------+---------------+-----------------+

(*) deferred locking, time-constrained attempts at locking, recursive
locking, transfer of lock ownership.

What do you think? I have had a hard time rewriting the proposal because
the actual name is bothering me :-)

`std::multi_lock`, yay or nay?

Best regards,
Ted Lyngmo

Ps.
On a sidenote: I have supplied an implementation of the proposal that
came before P3833, namely P3832R0 Timed lock algorithms for multiple
lockables, to the Beman project:
https://github.com/bemanproject/timed_lock_alg