O que significa "monotonicidade" no contexto da mutabilidade

Estou lendo a Linguagem de programação Rust e encontrei a seguinte passagem:

Lembre-se de que escrever em uma estrutura não é uma operação atômica, e muitas funções como vec.push()podem se realocar internamente e causar comportamento inseguro; portanto, mesmo a monotonicidade pode não ser suficiente para justificar UnsafeCell

Ele apareceu do nada no livro e tive um tempo difícil online tentando encontrar o que exatamente significa nesse contexto. Muita informação é sobre o conceito de "monotonicidade" de funções matemáticas, que eu já sabia, mas aparentemente não é muito útil.

Eu só parecia encontrar este artigo que fala sobre isso.

Agora, além de respeitar a igualdade da maneira óbvia, também incluo a estipulação de que um programa funcional deve respeitar a monotonicidade das observações. O que quero dizer com isso? Deve ser que, depois de observar algo em determinado momento, isso não deixe de ser evidente no futuro. Isso é análogo à propriedade de monotonicidade na semântica de Kripke ou Beth.

No entanto, isso também é bastante abstrato e não tenho certeza de que ele fale da mesma coisa.

O autor parece estar usando o mesmo conceito (geral) de "monotonicidade" que na matemática pura.

Usando o exemplo de a vector, se o tamanho de uma instância específica de vectorfor monotônico, seria razoável supor que a localização da memória de qualquer pushelemento ed anteriormente não será modificada posteriormente e, portanto, é seguro alterar diretamente o valor desse elemento sem ter que sincronizar com as operações vectorsubseqüentes push.

Essa suposição parece razoável pela mesma razão pela qual parece razoável supor que a localização da memória de um elemento previamente enviado para uma pilha (não circular, baseada em array, sem limites) cujo tamanho está aumentando estritamente não será afetada por um futuro pushOperação. Isto está em contraste com uma pilha em que ambos pushe popoperações estão a ser chamado, e por isso a localização na memória de um elemento previamente empurrada pode ser "removido" por uma popoperação, e assim disponível para ser atribuído a mais uma vez (ou seja modificado) por um pushoperação subseqüente .

O argumento do autor é que essa suposição não está correta, pois mesmo em uma estrutura de dados cujo tamanho está aumentando estritamente, inserções futuras podem afetar elementos inseridos anteriormente, acionando uma realocação interna de algum tipo que é distinta do efeito "lógico" da inserção .