> I see your point but would argue (in the most
> friendly way) that the case you point out would be extremely rare, while
> the reverse case is very common.

"Correctness" (in the context of software engineering) doesn't mean
doing the right thing in all but the rarest cases; it means doing the
right thing in every case.  Multiprocessor race conditions are
extremely rare, but that doesn't absolve us from putting locks around
critical sections in the kernel to guarantee that "rare" becomes
"never".

Remember mk is not just used to compile stuff.  It's a "general tool
for describing and maintaining dependencies between files or
programs".  If there are cases (even extremely rare ones) when mk can
finish without establishing all the described dependencies, it's
broken.  Given the simple low-resolution time stamps currenly
supported by the Plan 9 file protocol, ensuring that files are updated
correctly may come at a cost of doing some redundant work.

Think a bit further outside the box than a single-user computer being
used to compile programs.  Suppose for example there's a cron script
which uses mk to update indices for the lookman(1) command, or to
update hash files for ndb(8).  What if someone (maybe in another
timezone!) happens to be editing a man page or ndb file when the cron
job activates.  Oops, race condition.  Extremely rare like most race
conditions, but I for one am happy that mk is robust enough do the
right thing when the rare occurrence occurs.