Doesn't that mean that iteration requires a write lock? That sounds bad for lots of applications.

The write-lock is checked entirely at compile time, so no performance overhead

It sounds like that will prevent threads from mutating the tree in the (potential) presence of an iterator in some other part of the tree, which is prohibitively expensive for many applications.

Am I missing some clever trick?

No, that is correct.

There are ways to avoid locks, but the stdlib implemtation doesn't do it. There are probably a bunch of crates that implemented concurrent BTrees, though.