Does Grunt's internal file cache reliably invalidate when source timestamps change on virtual file systems?

Grunt caches processed files in an internal store and reuses them across runs unless explicitly cleared. The invalidation mechanism relies on file timestamps, which can behave inconsistently on networked or virtual file systems such as Docker volumes, WSL mounts, or NFS shares. This raises uncertainty about whether a modified source file will always produce a fresh build artifact without manual intervention.

Version differences between Grunt 1.x and 2.x may further affect reproducibility, and the --watch flag can trigger partial updates that leave stale entries in the cache. Node.js module resolution can also cause the same logical file to be cached under multiple paths, complicating invalidation.

1. Does Grunt's timestamp-based cache invalidation guarantee fresh output when source files change on virtual file systems where mtime precision is reduced?
2. Which Grunt versions or configuration flags provide deterministic cache clearing without requiring a full clean build?
3. Can the cache key generation be customized to incorporate content hashes instead of relying solely on filesystem timestamps?