I think that whole section should be rewritten -- the intent of that documentation has nothing to do with items being modified. It doesn't matter whether the items are modified or not, what matters is whether Ord returns contradictory results, i.e. results inconsistent with a linear order (which may happen regardless of whether anything is being modified).
Personally I think it would be totally sufficient to say that if Ord ever tells BTreeSet results inconsistent with a linear order, a panic may happen, or BTreeSet will pick a subset of those comparisons that does result in a linear order. In other words: if BTreeSet ever makes any redundant comparisons, and the results are contradictory, it will either panic or ignore some of them.
This was previously discussed at length here.
Using unsafe to modify items owned by BTreeMap<usize> would be unsound. I agree with @scottmcm that BTreeMap<usize> should always be in order, so any such new API should either verify the order or be unsafe.