Currently, if you write a code block in documentation, it gets interpreted as a doctest unless you mark it as not being tested, in which case you get a "This example is not tested" indicator on it. Likewise, if you mark it as a compile-fail test, you get a "This example deliberately fails to compile" marker.
However, sometimes you want to give examples of an incorrect usage that would compile but has undefined behaviour (e.g. a safety block saying "you must do X, because if you don't you might have undefined behaviour: example"). This doesn't fit very well into the current implementation of rustdoc: if you mark it as untested you get a warning about the code being untested that doesn't fit the situation very well, but if you don't mark it as untested then you have undefined behaviour in your tests, which is potentially risky due to the ability of undefined behaviour to do anything at all (and even if it does something relatively tame, it might still segfault the test runner).
Instead, it would make sense if code blocks could be explicitly marked as being unsound – this would cause them to not be used as doctests at all, but produce a different margin note talking about the code being unsound (or perhaps intentionally unsound – I'm not sure what the best wording would be), rather than a generic "untested" message. This would make it easier to document unsafe code because you could give examples of incorrect usage without needing to fight the documentation system.
(I can also see a potential division of this into code that should not be run at all, and "miri-fail" doctests which could plausibly be run under Miri to verify that it reports undefined behaviour on them. But that distinction probably shouldn't be visible in the generated HTML.)