Well, I don't know much about file systems, but isn't it always betterto be notified than to poll ? First, having a notification system
means it's instantaneous. Second, I'd imagine querying the state of afile has a cost (especially if it can't be cached and needs a realaccess to the hard drive). Third, it'd avoid a waste of CPU resources
(which may be important for power consumption, since, from what Iunderstood, the more a program has fixed timers, the more it wakes theCPU from sleep). Fourth, being notified is more high-level, since thenotification itself can be implemented by polling. One could imagine a
notification API where the backend would use inotify if available,polling if not.

> But it could also be a pain in the neck to have these changes occur> while you're moving around in the Dired buffer and making changes.

Agreed. Maybe couple it with a condition like "the user hasn't doneanything to the buffer for n seconds" ?

I also agree that notification for files shouldn't be turned on bydefault. When dealing with files that are modified in more than one
place at the same time, the simpler and safer the default is, thebetter. It would be interesting to provide the feature for advanced users though (ie users who know what they want). In any case, an inotify API could be a nice basis for customisation/other modes (kinda like the dbus interface)