I voted for lightweight, but that's because it was mostly what I thought would be the best feature. The exact feature would be that each function has explicitly one well-defined function, and most certainly not multiple.
This is their order of importance for me:
Lightweightness(?): one API function should only do one, simple thing
Simplicity: most common things should be as simple to do as possible
Transparency: the API can be extended and even partially bypassed without writing extensive amounts of glue code
Consistency: the API as a whole follows the same few principles
Completeness: covers most of what anyone would want to do
Modularity: one can use certain parts of an API without fully commiting to the API model as a whole
Examples:
Lightweightness: good, close(int fd). It closes a file descriptor, no questions asked. Bad: Open(int fd, int mode[, int flags]). It either opens a file, truncates a file, opens it for append, creates an entirely new file... and if you don't specify the optional flags you end up with a setgid nobody-read-or-writable file. Other examples include ioctl and fcntl.
Simplicity: There should be no complex functions. See lightweightness for description, the same two are good and bad. Although I'd pick fcntl this time
Transparency: You should be able to hide the entire API very quickly behind your own facade, making it very accessible for people that don't like it, or that like complex functions or anything. It also should allow easy (well... relatively) access from OO languages, since there are numerous people using them. Good design would be for instance fork(), since it doesn't hold anything non-portable to OO design. Bad design in this case is pthread_create, in that you have to create a static function for each call you'd like to make, with a struct to go with it.
Consistency: Each function uses the same execution idea, and not a completely different one. Good would be the unix stuff, where socket() returns an fd, open() returns one, and you can open devices of all types also returning an fd. In Windows you get a few different types, and you have to use different functions with equivalent names for the access, not making it any clearer (read or recv or ..., send or write or ...) for people first learning it.
Completeness: I don't like having features inaccessible, but in most cases no OS designer leaves out essential features. The nonessential ones are built up from the essential ones, so that allows you to make them yourself, in effect, making them complete again. This thus doesn't weigh high for me.
Modularity: I am kind of missing the point of this one. Why would you want to be able not to use an API, or parts of it, if there's no other API in the OS? Do you imply mix&match fishing-up your own API? That's a bad thing. You'll make code that others can't read, and you can't read others code. Use one API for the language, and make it clear. If others want a different one, kind of, tough.
In short, I like functions that are simple to use, do one thing, preferably do them well (pretty DUH) and have no unintended side-effects (say, a close that randomly picks a fd, open that doesn't give anybody access).
