Maybe a comment for part 2, but getting APIs right is important. For a counter-example, look at the Service Availability Forum APIs. They use C structure pointers as parameters to functions. As the first version of the API was used, improvements were made. The standard doesn't come with an implementation, so there was no feedback to the API until people started to implement it. As they found that there were missing or new pieces which needed to be added to the structures, a backwards compatibility issue arose. To solve it, new structures were created with a number appended to the structure to version control the structure. That, of course, caused the function to take a different parameter type, so the function name got a number appended. This would allow an unchanged client to use the associate library, while an updated client could use the new functionality.
If APIs are likely to be extended in the future, the API needs to allow for that. This generally means that the callers will have unattractive code as they fill out the data to call the function in an extensible manner. There are a couple of ways to build extensible data. One is to use opaque objects with setters and getters. The other is to use tag/value lists, which is quite often the underlying mechanism for setters and getters. It's unattractive, but better than trying to remember if the disinter_3 function takes the Foo_2 or Foo_3 argument type.