Not a "serious" application developer in OS/2 land, I've coded some here and there.
The OS/2 API seems more than capable for everything I have wanted to do, I missed nothing -- I don't do 3D multimedia animation, or anything that flourished after the API was fleshed out, where I suspects most real lacks (if any) must lie. Sometimes the API forces doing things in a way that seems strange to me, but that may be because I'm not familiar enough with it. However, as the large file API has been mentioned, I'll say I'd like to see a 'clean' approach in some areas, *if* it's possible, and I'll use that as an example:
When file sizes were limited to 2GB, file position pointers, etc. could be expressed by a four-byte natural number (2^32 = 4GB), and that's the size of most file handling API arguments at the time. Support for anything beyond that "naturally" required new functions with would allow wider arguments, hence we have a parallel file API for large files.
From my point of view as a non-specialist in low-level implementation of such APIs, I'd like to have one working set of file APIs that would do its thing according to argument size (> vs <= 32 bits for starters), and any necessary redirecting APIs to address legacy applications. All APIs should be 'open' regarding that (argument size, or even number) if I am getting the point across (am I?). The FTP protocol comes to mind to further illustrate the point: at some point we needed newer clients and servers that could do 'huge' files; no protocol changes were necessary because that was handled in a more future-proof way (IIRC file size is transmitted as a decimal string, so any limitations of that are WAY into the future).