I don't think the language should include your idea. It is generally ill advised/non-standard functionality and is only for covering what iI consider a design usage flaw with your update/change/notification mechanism. It does not add any useful functionality that is not already available through the use of otherwise simple normal coding techniques.
I believe using a technique demonstrated in this Godbolt link does everything, all the flavors, of all the options, including function grouping, without any extra overhead, other than what you were already asking for, without changing the language. Plus by directly including it in your code, shows intent and it does not hide any functionality.
"Yes, and..." Looking at that code, I see that it suffers from the same problem I keep asking Frederick to address: he hasn't said what the code is supposed to do in the "failure" case. Your implementation uses a variable named "unblocked," as if there's a mode in which the code would block and wait for... something... to happen. But in fact your code never blocks. If a reentrant call is attempted, the... whole function body... is just... skipped?!
(1) There's no way this is what the programmer actually intended.
(2) How would you skip the body of a function that has a non-void return type?
Frederick has said that the functionality of his feature would be to "prevent" calls that are "reentrant." Defining what that means has two parts:
(A) Define what makes a call "reentrant." This is relatively well addressed.
(B) Define what it means to "prevent" a call. This has not been addressed at all.
Compare to std::once_flag, which "prevents" multiple callers from entering the same critical section at once: what it means by "prevent" is "everyone who's not the owner of the once_flag must block and wait until the current owner completes the block; if successful, all waiters unblock and skip the critical section; if failed, exactly one waiter unblocks and attempts the critical section again."
Frederick needs to describe the semantics of his new synchronization primitive in the same sense. Who blocks, how do they get unblocked, etc.
(Frederick has also said things like "The block only applies to..." which makes me think he's unclear on the English jargon meaning of the verb "to block"/"to wait" in concurrency in general.)
–Arthur