What I described was for bugfixes, not features. Features were set in stone way before this.

I also maintain that it is impossible to know which changes depend on other changes. In one case, applying a bugfix that changed the order of allocations at startup caused vtable corruption somewhere else because it changed how much padding a particular malloc() call was returning, and someone was writing past the end of their allocation.

[edit]

Also note that what you described is not CI; things are developed on their own branches and not integrated immediately.

It's may seem like a nitpick but I think it's a whole different way off looking at it to phrase it as "applying a bugfix that changed the order of allocations at startup exposed memory corruption somewhere else"

I do think there is something to be said for both perspectives, especially for code that is extremely critical. With sufficient testing and determinism maybe you can actually make sure that dormant issues stay dormant meaning there is real value in being change-averse. Still it's a very precarious situation having a known memory corruption hoping it's the testing has made sure its benign in practice.