I can help explain some more advanced scenarios with the Add-In API.
The Add-In API is designed around two primary ways of using it:
1. Low level "access to everything" interfaces to use all nitty-gritty bits of the API itself. The add-in developer is responsible for hooking everything up, etc.
2. Scenario-based usages: this is where the abstract base class helpers come into play. QueueMonitor and AddInWindow are two examples of that. Each one focuses on a scenario (monitoring a queue, or adding a window) and does some of the add-in API grunt work needed so that the add-in developer only has to override a few methods and can focus on implementing their own logic.
That said, for your specific questions:
If you want to do a client window that shows interaction details, then you aren't going to be able to take advantage of the QueueMonitor and AddInWindow helper classes. You're going to have to create a class that implements the IAddIn interface and then uses the IQueueService to retrieve an IQueue instance, as well as uses IWindowManager to register an IWindow implementation, and hooks all of that up together so that all the relevant components know how to talk to each other appropriately.
That said, we do have an SCR to add helpers for this particular scenario since it has come up more than once. We also have an SCR to add an add-in API to allow access to retrieve the currently selected interaction in the "My Interactions" view, so that you could (for example) add a custom window that displays information about the currently selected interaction and the user could then select new interactions to view information about them. Both of these SCRs have a lower priority currently due to the efforts underway to get our new release out, but they do exist.
As for combining Add-Ins with IceLib, I mentioned it in a reply to another post, but yes, this is possible if your server has the IceLib SDK license applied to it. If it does, you can retrieve the client's IceLib Session instance and use it. But this comes with a huge warning: there can be undefined behavior as a result. If you disconnect the session, the client will disconnect from the server. This is a very low level and invasive thing, so use it with care. There are other scenarios also where undefined behavior can occur due to internal design decisions/tradeoffs in the client itself.
The rule of thumb regarding using the Session is this: if there is an Add-In API to do what you want (queue monitor, interaction watch, etc.) then use the Add-In API. If there isn't an API for it, you can use the IceLib Session. (For example, changing the user's status, sending custom notifications, etc.)
Also, when you deploy your add-in, ensure that only your add-in specific binaries are installed in the client's "addins" subdirectory. We've tried to protect against it but there are some cases where including "duplicate" binaries (like ININ.IceLib.dll, for example) can cause odd behavior due to how .NET identifies and loads assemblies.
Hopefully that helps, I would very much like to produce some screencasts to demonstrate some more advanced scenarios, but time for that has been in short supply lately. I'm hoping to get more done in this area after our next release is finished.