Yes, I see. We'll have to decide where's the error, or what's the intended behavior.
test-native-compile-prune-cache sets native-comp-eln-load-path to a single directory and then tests whether native-compile-prune-cache can delete a stale cache dir inside it (and keep a non-stale one).
It is obviously going to fail with my fix, because with it installed, native-compile-prune-cache is never going to delete anything in the last (or, in this case, unique) directory in native-comp-eln-load-path, because, as the docstring of native-comp-eln-load-path says, "[t]he last directory of this list is assumed to be the system one" (i.e, the one containing the preloaded/ subdirectory and its content).
So, alternatives:
1.- We fix the test so it sets native-comp-eln-load-path to a list of two directories, and checks that the stale subdir is deleted in the first, and nothing is deleted in the second ("system") one.
2.- We remove my change and allow that native-compile-prune-cache sometimes deletes files in the "system" eln cache, but Eli argued that we don't know if the user will have write access to it, and we're not sure we *want* to allow native-compile-prune-cache to delete files there...
3.- Or we find a way to reliably decide whether a cache directory is, in fact, the "system" one (which we can currently do, heuristically, because it contains preloaded/), and fix *both* my patch and the test so it only considers untouchable those cache directories that really are "system" ones.