I recently added AE2 support to Building Gadgets, allowing a gadget to be bound to an AE network as a remote inventory. Here's my implementation: https://github.com/Direwolf20-MC/BuildingGadgets/blob/master/src/main/java/com/direwolf20/buildinggadgets/common/integration/mods/AppliedEnergistics2.java

The problem is that I ended up having to reference core classes, rather than just the API, for stack insertion/extraction. Would it be possible to add to IMEMonitor versions of injectItems/extractItems that take a player (or just expose PlayerSource), and provide a means of getting an IAEItemStack from an ItemStack via the API, to avoid this?

Ahh thanks, that works. And I suppose PlayerSource isn't worth exposing, given how simple a custom implementation is. Also, the wrapped network isn't cached for use; so it should be fine.

This is already possible, e.g. via IStorageChannel or it accepts a custom implementation like IActionSource.

Also on a first glance, it looks like a potential performance hog depending on how it's used with large inventories. At least when trying to be consistent with the actually available inventory. Otherwise it will just deviate from it and probably operate on an incorrect version of it.

Yes, the IActionSource is a somewhat more recent (reworked) part of the API. Previously we provided some basic ones as part of the API, which were actually required to be used and pretty often other mods would ignore it and pass their own implementations around. Therefore we try to move newer API functionality to a simple interface anyone could implement and if really necessary provide some factory method to construct an internal class for decorating it or similar.

Not caching the list would actually be the main issue depending on how often StackProviderAE2.getStack() is used. Creating itemstacks really does not scale well thanks to caps on them. E.g.
And that is without anything attaching caps to them. With it, it should be even worse. It is of course a somewhat extreme example, but certainly something to be taken into consideration. At least for large servers or similar applications.

It's cached for rendering, but the cache only updates every 5 seconds. And though it's not cached for use, it's only used once each time one actually clicks to perform/undo a building/exchanging operation.