@PhrostByte it is very easy to invalidate this, constant member functions do not enforce referentially transparency (pure functions) even in C++11. You can still modify global or (class) static unsynchronized variables in constant member functions or modify unsynchronized data members marked as mutable.
You can say this is a bug/undefined behavior (in the context of concurrent/parallel code) but this is an issue with the language/library if the standard say that constant member functions must be side-effect free but the language does not enforce this thus the compiler will never enforce this.
From my point of view const does not guarantee thread safety, this is only a promise that can be silently broken. This is not particular useful.
This change in C++11 is actually a breaking but silent change to existing code and you have no help from the language/compiler to find and fix any buggy code which is not C++11 compliant.
In other words, it's no different from most everything else in C++ -- helping you a good deal but still not "enforcing" anything, allowing you to do whatever the hell you want in the end
A compiler may not be able to catch and warn about all instances of broken code (you're right, this is a breaking change), but there's a lot of room here for it to help.