Proposed resolution:

Change [res.on.objects] as indicated:

The behavior of a program is undefined if calls to standard library functions from different threads may introduce a data race. The conditions under which this may occur are specified in 17.6.4.7.

[Note: Modifying an object of a standard library type shared between threads risks undefined behavior unless objects of the type are explicitly specified as being sharable without data races or the user supplies a locking mechanism. --end note]

[ 2009-10 Santa Cruz: ]

Note: Change to read: "Modifying...", Delete 'thus', move to Ready

[ Batavia (2009-05): ]

The proposed wording seems to need a bit of tweaking ("really bad idea" isn't quite up to standardese). We would like feedback as to whether the original Note's removal was intentional.

Change the phrase "is a really bad idea" to "risks undefined behavior" and move to Review status.

N2775, Small library thread-safety revisions, among other changes, removed a note from [res.on.objects] that read:

[Note: This prohibition against concurrent non-const access means that modifying an object of a standard library type shared between threads without using a locking mechanism may result in a data race. --end note.]

That resulted in wording which is technically correct but can only be understood by reading the lengthy and complex [res.on.data.races] Data race avoidance. This has the effect of making [res.on.objects] unclear, and has already resulted in a query to the LWG reflector. See c++std-lib-23194.