Accessing unrelated objects on destruction/deletion does not quite fit the shared_ptr/weak_ptr philosophy.

I take for granted that you're right about this ! I was more thinking about the 'instantness' and not about the 'implicit coupling / lifetime dependency' :)

This introduces data races and coupling and locking issues in the presence of multiple threads.

You have a very good point here. I'm far from being proficient when comes threading issues and lock free programming.

In fact, my current usage pattern of this construct is quite similar to A. Alexandrescu's WRRM map (Write Rarely Read Many) in this article. So, it is perhaps possible to have a similar contruct, with a minimalist interface (say only query / update), and only returning copies of stored objects.

This way, the client have, when queried, a full copy of the value - that won't be deleted under its feet. That could come in complement to the fact that, for querying you need to hold a shared_ptr on the key, which should prevent another thread to delete the key instance during the query.