The thing is, Debian's solvers are always deterministic. Given from a known state, it always ends int the same state. This allows getting/setting selection lists with "dselect", and using apt for system automation feasible.
In my last decade (or 15 years to be exact) with Debian, I never suffered from non-deterministic behavior or met with surprises from apt.
The solver might be deterministic if you take some sufficiently large global state into account, but the process of
apt install bar
from a users view is not. It can have a different result depending on what is already installed, or even if all other system state is the same it can change with time.
My point is that a package "bar v3.2.1" that depends on "libfoo v1.2.3" needs to be considered a different package than "bar v3.2.1" that depends on "libfoo v1.2.4" or even "libfoo v1.2.3 compiled with -O3 instead of -O2", because the resulting package can behave differently due to the variation.
But as soon as you have that there is no need for install time dependency resolution anymore, since it is all done at build time.
It might get better now. Packages often have dependency loops, so that "A depends on B depends on C depends on A". Autodependencies in a loop like that would never get uninstalled.
One of the more obscure outcomes of that is if you later installed something else that had one of those autodepends as a less favoured alternative, it would be used regardless - ie instead of what the package you were installing said it preferred.
I'm guessing this fixes that particular wart. By starting from a blank slate every time it effectively ignores those autodepend loops, so they will get uninstalled.
In my last decade (or 15 years to be exact) with Debian, I never suffered from non-deterministic behavior or met with surprises from apt.