According to both links you posted, the query cache caches the IDs resulting from the query and starts fetching entities one by one: if you have them in your cache, great, if not, bad luck, you now have many selects.
At this point I presume that the entities that you are selecting are not in the second level cache (anymore?). I never used table based dependencies, we are using command based dependencies, and I just tested that if an entity is marked as invalid, only this cached entity, and not the whole cache region, is thrown out of the cache.
Check the configuration to be sure that it is correct, maybe when you think you are hitting the second level cache you are actually hitting the session cache? Be sure that you are testing that the cache is working across different sessions.
In any case I advise you to look into the DEBUG level logs of NHibernate and see what is actually happening with the second level cache, there you will be able to see all cache hits/misses. Another tip I can give you is to enable the generate_statistics flag in your configuration. Fluent:
config.ExposeConfiguration(c => c.SetProperty("generate_statistics", "true"));
After this you can access interesting data in the session factory such as Session.SessionFactory.Statistics.SecondLevelCacheMissCount
and Session.SessionFactory.Statistics.SecondLevelCacheHitCount
. With the combination of these two methods you should be able to pinpoint the cause of the problem.