> What I would really like is the ability to change defaults for all mutexes created in the program, and have everyone use the same std mutexes.

Yes. I imagine subbing out a debug mutex implementation that tracks lock ordering and warns about order inversion (similar to things like witness(4)): https://man.freebsd.org/cgi/man.cgi?witness(4)

> rwlocks are often a bad idea

Yes.

> since you still get cache contention between readers on the counter for number of active readers

There are rwlock impls that put the reader counts on distinct cache lines per core, or something like that (e.g., folly::SharedMutex), mitigating this particular problem. But it isn't the only problem with rwlocks.

> Consider alternatives like seqlocks, RCU, hazard pointers etc instead, depending on the specifics of your situation (there is no silver bullet when it comes to performance in concurrent primtitves).

Yes. :)