Just to give you an example of what I'm talking about: the
gzipdirective documented here is defined by the HttpGzipModule. All this module had to do was to tell nginx: "gzip" is one of my directives, it takes one argument that can be a flag and you can find it at any level you wish in the configuration (main, server or location). If, like me in the good old days, you've done some parsing yourself and/or tried to do something nifty with command-line arguments you will recognize this is good and nice.
Now, one thing that I find kind of problematic: the flags that let you define what to expect are not very well designed and some of them overlap. As an example, the flags NGX_CONF_TAKE1 and NGX_CONF_FLAG both tell "there is only one argument". Admittedly, NGX_CONF_FLAG says a bit more than that (it's one argument and it's a flag) but nothing in the interface (a bitwise combination of these flags) forces the module developer to avoid using both. Or worth: to use conflicting ones like NGX_CONF_TAKE6|NGX_CONF_FLAG. And there is no "right" way to implement this. All you can do is document it and hope that the developer will read the documentation (personally, I don't know a lot who do). If they don't, they'll eventually fall in the trap and complain that they got hurt.
Bottom-line: that is exactly why I tend to avoid bitwise flags in interfaces. I'm not smart enough to make sure I get all the possibilities right. So, instead I go for less "efficient" interfaces but interfaces that cannot be misused. Better safe than sorry...