Hmm, based on what I remember from study long ago... to say that IAC can be extended is rather stretching a point. But a plug-in can certainly expose IAC methods, using COM or other interfaces, to other apps. Particular Complications.
1. It gets messy because the OLE objects in Acrobat's IAC methods are opaque to their IAC; a plug-in has no hooks to convert a received OLE object from AVDoc (OLE) to AVDoc (plug-in). That said, there are probably ingenious ways to at least convert AVDoc and PDDoc objects.
2. A plug-in must not wait, but providing a service is typically based on waiting. This may be overcome using a secondary thread but...
3. The plug-in API can only be used from the main thread, and there is no way to call a routine in the main thread. This means that messages would have to be posted to the main thread, perhaps using Windows messages, perhaps using Idle procs.
So how do you expose IAC methods through a plug-in? After all they are already exposed to external apps. That's the whole point of the IAC.
That last bit in the sentence, " core API objects that are not already part of the IAC support system." implies the IAC can be extended to more than is already there. That in fact custom functionality can be added to the IAC. If this is true, then it's a great thing. Cause the only other ways to pass data from an external app to an Acrobat plug-in is DDE, or indirectly through JS. There are probably also some existing IAC methods that could be used for this purpose, but I'm very keen on the more direct approach if it is possible.
Looks like the answer is in the References, although I won't be able to test it right away to be sure.
There are two functions for handling COM interfaces. One in the plug-in SDK, and one in the IAC SDK.
WinAppRegisterInterface - on the plug-in side registers a COM interface with Acrobat.
GetInterface - On the IAC side acquires the interface.
It would be nice if these functions, or more info on the process was mentioned/linked on the page that mentions it's possible.