@feld @pertho Doesn't feel like something I'd like to try though. It would be pretty much #FreeBSD-specific, but worse than that, you shouldn't rely on dtrace availability, as it's an optionally loadable profiling tool (so, it would also be a "misuse" regarding purpose). Related to that, I'm pretty sure it requires superuser privileges for everything, which would be another issue for some general-purpose application software.
No, the "canonical" solution for filesystem watching on a BSD system is indeed #kqueue. And unfortunately, it does fall short a bit compared to #Linux' #inotify. For my #xmoji tool, I wanted notifications about any change on the runtime configuration file, and additionally to the pure #POSIX solution of periodically calling stat() (which is stupid, but still works for a single file), I implemented backends for both inotify and kqueue. For just a single file, kqueue's requirement of having an open file descriptor is just a minor annoyance, but you can deal with that. Note it's not as simple as it sounds in any case, e.g. when the file is deleted, you want to watch the directory of course, so you learn when it's re-created ... which with kqueue requires opendir() 
... still doable. But for scenarios where you want to watch a whole tree with potentially lots of files and directories, this is really bad and #inotify really shines.
construct and in BSD land 
monitoring the file system is part of 
... just need to document the new feature (history) and build knobs (kqueue/inotify) first.
