message: update comment based on further research
diff: @@ -744,10 +744,23 @@ where
  return true;
  }
  };
  - // Equal mtimes could mean that the input was changed in that same second,
  - // but *after* the output was generated. So this means they are stale.
  - // In theory, cargo is using nanosecond precision throughout so this
  - // should not make a difference -- but it was necessary to fix #5918.
  +
  + // Note that equal mtimes are considered "stale". For filesystems with
  + // not much timestamp precision like 1s this is a conservative approximation
  + // to handle the case where a file is modified within the same second after
  + // a build finishes. We want to make sure that incremental rebuilds pick that up!
  + //
  + // For filesystems with nanosecond precision it's been seen in the wild that
  + // its "nanosecond precision" isn't really nanosecond-accurate. It turns out that
  + // kernels may cache the current time so files created at different times actually
  + // list the same nanosecond precision. Some digging on #5919 picked up that the
  + // kernel caches the current time between timer ticks, which could mean that if
  + // a file is updated at most 10ms after a build finishes then Cargo may not
  + // pick up the build changes.
  + //
  + // All in all, the equality check here is a conservative assumption that,
  + // if equal, files were changed just after a previous build finished.
  + // It's hoped this doesn't cause too many issues in practice!
  if mtime2 >= mtime {
  info!("stale: {} -- {} vs {}", path.display(), mtime2, mtime);
  true
  