In other places we say "The calling thread shall own the mutex"

Well, in one other place. And then in other places we say "does not own the mutex" rather than "shall not own..." so I'm not sure which of those to be consistent with!

In core, there is largely agreement that "shall" means "the program is ill-formed unless" (and core tends to clean up other uses of "shall" as it sees them).

In the library, we have a mixture of "shall" as a requirement on the implementation, "shall" as a requirement on the program where a violation results in the program being ill-formed, and "shall" as a requirement on the program where a violation results in undefined behavior.

@StephanTLavavej, @jwakely: Has LWG expressed any preference on which of these meanings of "shall" they'd prefer to use (or even considered the issue)? If LWG hasn't expressed an opinion, I think we could use a guideline such as 'a "shall" violation means ill-formed in core and UB in library', which would make "shall" appropriate in this case.

I don't think it's been considered, except indirectly when we're reviewing someone's paper, and we want to know whether they want to mandate enforcement or not.

In my opinion, we should be consistent with 17.6.4.11 [res.on.required]/1 and 17.6.4.8 [res.on.functions]/1 which say that violating Library requirements triggers UB. The Library has recently been mandating enforcement by specifically saying "ill-formed", which is a nice signal to implementers that they need to static_assert or otherwise explode. It would also be nice to have a different style of wording for requirements placed on implementations. Not sure what the right mix of editorial conventions is.

@zygoloid: As a reader, I'm curious is it intended to be discussed separately for core and library by committee? Would there better be something in [intro.compliance] to clarify what "shall" and "shall not" mean in the whole standard, just like ISO C Clause 4 (esp. p1 and p2)?

Let's move the general discussion to #1086 (where we can actually find it), because the specific issue here (as mentioned in the title) is fixed.