You have 3 types of testing unit (descrete part of code), integration (how a software piece works with others) and system testing (e.g. the software running in its environment). Modern software development has build chains to simplify testing all 3 levels.
Debian's change freeze effectively puts a known state of software through system testing. The downside its effecitvely 'free play' testing of the software so it requires a big pool of users and a lot of time to be effective. This means software in debian can use releases up to 3 years old.
Something like Fedora relies on the test packs built into the open source software, the issue here is testing in open source world is really variable in quality. So somethinng like Fedora can pull down broken code that passes its tests and compiles.
The immutable concept is about testing a core set of utilities so you can run the containers of software on top. You haven't stopped the code in the containers being released with bugs or breaking changes you've just given yourself a means to back out of it. It's a band aid to the actual problem.
The solution is to look at core parts of the software stack and look to improve the test infrastructure, phoronix manages to run the latest Kernel's on various types of hardware for benchmarking, why hasn't the Linux foundation set up a computing hall to compile and run system level testing for staged changes?
Similarly website's are largely developed with all 3 levels of testing, using things like Jest/Mocha/etc.. for Unit/Integration testing and Robots/Cypress/Selenium/Storybook/etc.. for system testing. While GTK and KDE apps all have unit/integration tests where are the system level test frameworks?
All this is kinda boring while 'containers!' is exciting new technology