Proposed resolution:

Change [util.smartptr.shared.obs] p12:

[Note: use_count() is not necessarily efficient. Use only for debugging and testing purposes, not for production code. --end note]

Change [util.smartptr.weak.obs] p3:

[Note: use_count() is not necessarily efficient. Use only for debugging and testing purposes, not for production code. --end note]

Peter Dimov wrote: To: C++ libraries mailing list Message c++std-lib-15614 [...] The intent is for both use_count() and unique() to work in a threaded environment. They are intrinsically prone to race conditions, but they never return garbage.

This is a crucial piece of information that I really wish were captured in the text. Having this in a non-normative note would have made everything crystal clear to me and probably stopped me from ever starting this discussion :) Instead, the sentence in p12 "use only for debugging and testing purposes, not for production code" very strongly suggests that implementations can and even are encouraged to return garbage (when threads are involved) for performance reasons.

How about adding an informative note along these lines:

Note: Implementations are encouraged to provide well-defined behavior for use_count() and unique() even in the presence of multiple threads.

I don't necessarily insist on the exact wording, just that we capture the intent.