This is not just about broken programs. While it is true that deadlock-on-relock could give you some kind of fail-stop behavior in a program that incorrectly tries to acquire a non-recursive mutex twice, not all programs that deadlock-on-relock need to be necessarily broken.
In particular, they can still handle signals, and a deadlock-on-relock situation will not prevent a program from shutting down. For example, deadlock-on-relock might be a valid way to suspend a thread until program termination. Thus, this kind of deadlock is not necessarily an obstacle to forward progress, so you can't for sure say it's a bug. glibc's lock elision implementation guidelines (http://sourceware.org/glibc/wiki/LockElisionGuide) have further examples, as well as a more detailed discussion of POSIX semantics vs. purely HTM-based lock elision implementations.