I was reading the aptitude manual and I think I found the description of this behaviour.
Little recap, aptitude doesn't suggest the "right" packages dependency solution as a first choice (you need to tell him couple of NOs before getting to right combination) when trying to install an old version of a package (apache in this case) coming from a snapshot repository of an older Debian release.
According to the manual, aptitude has two algorithms for resolving dependencies. The manual labels these algorithms as "immediate resolution" and "interactive resolution". http://aptitude.alioth.debian.org/doc/e ... 03s01.html
The first algorithm ("immediate resolution")
It is invoked whenever you select a package for installation interactively, and immediately after one or more packages are marked for installation at the command-line. Immediate resolution is fast and will solve most dependency problems, but it is sometimes unable to find any solution.
while the second one ("interactive resolution")
In the manuale here http://aptitude.alioth.debian.org/doc/e ... 03s02.html it also says about the "immediate resolution" algorithm:is invoked when packages have broken dependencies even after immediate resolution[11]. It can resolve more dependencies, it allows you to review a solution before applying it, and it allows you to provide feedback to the resolver, guiding it towards a better solution.
with apt-cache policy I checked the candidate versions of apache and its dependencies and the candidate versions (obviously) are 2.4.10-10+deb8u8.A dependency might not be satisfiable due to version restrictions and due to the limitation that only candidate versions are considered. For instance, say that versions 1.0 and 2.0 of fileutils are available, that the candidate version is 1.0, and that the package octopus declares a dependency “Depends: fileutils (>= 2.0)”. Immediate resolution is unable to resolve this dependency: it will never consider version 2.0 of the package, since that is not the candidate version.
So I guess that must be it.
If I'm not misunderstanding the manual, aptitude (just like it happens with apt-get) executes the "immediate resolution" first, which never takes into consideration the possibility of installing a version different from the candidate one.
When you don't accept the solution, it falls back on the "interactive resolution" which (I'm guessing here) tries to resolve the dependencies but still prefers to install the candidate versions if possible. That's why you need to give him a couple of NOs before he finally decides to select the old version of all the dependencies.
It seems to follow the behaviour described in the manual.