Add-In Limitations - Is There a Comprehensive List / Object Model?

GreigOldford

I've been searching now for a while and can't find an explicit list of the limitations of the component framework exposed to add-in developers (apologies if this is a redundant topic but I just can't seem to find this info). 

I've found this (from here😞

Most developers will create add-ins if creating a command, tool, combo box, menu or context menu, multi-item, toolbar, tool palette, dockable window, or application extension. However, if multiple interfaces need to be inherited, or if registration is required, an add-in will not work and a custom component needs to be created. For more information, see Building add-ins for ArcGIS Desktop.

Can anyone help me understand the multiple interfaces inherited clause?  For example, in an extension I have to gain access to the Utility Network Analyst toolbar and get the current network.  Is this a case of multiple interfaces being inherited in my extension?

From here I found this:

for example, you cannot write a custom renderer, a custom workspace, or a custom feature as an add-in. You will need to use the classic COM extensibility approach if your solution includes component types that are unsupported in the add-in framework.

Custom workspaces, feature classes, etc. are not supported.  Does this mean I can't create a non-spatial Table Feature Class in a user-specified GDB?  

This coding patterns here are helpful to get started but I have a large standalone extension to migrate from 9.x to 10 and would like to figure out if I could convert it to an add-in. In conclusion, I can't find the 'add-in framework' for reference of the complete list and any help would be great.