Ci sono un paio di cose che rendono la retrocompatibilità non banale.
In primo luogo, un vincolo che viene spesso utilizzato è che il tuo codice verrà compilato senza modifiche in una modifica compatibile con le versioni precedenti mentre in una modifica non retrocompatibile potrebbe richiedere modifiche al codice per la compilazione del codice rispetto alla nuova versione. Ovviamente, questo vincolo non è utile per JavaScript.
Questo porta all'idea generale, ovvero che il pubblico "contratto" del codice non cambia. I tipi sono una formalizzazione di un'approssimazione del contratto pubblico. Una suite di test è un'altra formalizzazione di un'approssimazione del contratto pubblico. Cioè, in una modifica compatibile con le versioni precedenti, tutti i test nella vecchia suite di test dovrebbero ancora passare. Sfortunatamente, ciò che fa parte del contratto pubblico non è quasi mai specificato in modo completo e spesso non è nemmeno completamente specificato in alcun modo. Il contratto pubblico è ciò che gli sviluppatori della biblioteca si impegnano a mantenere e l'unica cosa su cui puoi fare affidamento come consumatore, ma, soprattutto in un linguaggio come JavaScript, ci sono miriadi di dettagli che sono anche visibili che non fanno parte del pubblico contratto e quindi non può essere invocato. Ovviamente, questo non impedisce alle persone di affidarsi a loro.
Infine, c'è il caso imbarazzante in cui una biblioteca non rispetta il proprio contratto pubblico, cioè è buggy. In questo caso, i consumatori sono ovviamente costretti a fare affidamento sul comportamento effettivo della biblioteca e non sul suo comportamento previsto. Risolvere il problema, portando la biblioteca più in linea con il suo contratto pubblico, interromperà questi consumatori. Evitarlo si chiama mantenimento di compatibilità dei bug ed è un incubo che la maggior parte degli sviluppatori vuole evitare. Direi che il "consenso non espresso" è che i bug possono essere risolti senza preavviso.
In definitiva, è difficile apportare modifiche significative a una base di codice (a differenza di un'aggiunta pura), specialmente in un linguaggio come JavaScript, che non produce differenze osservabili a livello di codice. Ciò che serve come indicazione (parziale, informale) del contratto pubblico lascia di solito poco chiaro quale comportamento sia garantito in vari casi angolari. Anche data una specifica completa, di solito è proibitivamente costoso verificare effettivamente che il codice lo soddisfi. Quindi, alla fine della giornata, ciò che costituisce "retrocompatibile" di solito non è delineato nettamente, e anche se fosse (in senso significativo) sarebbe probabilmente troppo costoso per verificarlo realmente.
Quindi, sì, gli sviluppatori sperano che il cambiamento sia "retrocompatibile", proprio come sperano che il codice si comporti come è specificato nominalmente, ma tutti sono stati intorno al blocco abbastanza volte per sapere che tali speranze sono infondate.