Is your feature request related to a problem? Please describe.
The Dimensional Storage Actuator doesn't correctly report the stored item counts to other mod's inventory introspection features. For example, monitoring a Dimensional Storage Actuator with Botania's Corporea will report only a single item stack even if there are multiple stacks of items stored. 200 wheat is reported as 64. Here are images demonstrating the issue:

Similarly, adding multiple Corporea Sparks to the same Storage Actuator (via wormholes) will duplicate the item counts (Corporea will treat it as two separate inventories), as seen here:

Describe the solution you'd like
Ideally I would like if the Storage Actuator would correctly report item counts to other mods, and for wormholes to proxy to the actuator for item transport capability, rather than act as their own ItemHandlers. I am unsure if this is easily done, but I do know it is possible, because it worked with Arcane Archive's storage networks in 1.12. Perhaps looking at their code might shed some light on how to achieve it.

Additional context
Provided above.

ad item counts: The storage actuator does not "report" item counts - it simply provides an item capability handler for other mods to handle as they need (as do most storages, because that's the system used by vanilla). Wrong item counts happen if the other side does not take into account max stack size. The actuator has a stack size of 1024 in order to improve performance (speed & memory / network bandwidth usage) with (very) large storage counts.

Changes to that are currently not planned, however I can make the stack size configurable if that is desired - but I cannot account for side effects of changing the stack size or negative performance impact of a low stack size. Please do open a separate ticket if this is desirable.

ad capability: The wormhole already acts as a proxy, it finds the linked storage controller and forwards the capability from that controller. It does not have an item handle of its own:

    @Nonnull
    @Override
    public <T> LazyOptional<T> getCapability(@Nonnull Capability<T> cap, Direction side) {
        if (this.getLinkedStorageController() != null) {
            return ((TileEntity) this.getLinkedStorageController()).getCapability(cap, side);
        }
        return super.getCapability(cap, side);
    }

I assume corporea does not compare the capability references it gets from the wormholes and instead probably uses the block position of the tile entity (which is not unreasonable in 99% of all scenarios).

I'm closing this ticket as there are not changes directly related to it, but please feel free to make further comments or create new issues related to this!

ad item counts: The storage actuator does not "report" item counts - it simply provides an item capability handler for other mods to handle as they need (as do most storages, because that's the system used by vanilla). Wrong item counts happen if the other side does not take into account max stack size. The actuator has a stack size of 1024 in order to improve performance (speed & memory / network bandwidth usage) with (very) large storage counts.

Changes to that are currently not planned, however I can make the stack size configurable if that is desired - but I cannot account for side effects of changing the stack size or negative performance impact of a low stack size. Please do open a separate ticket if this is desirable.

I just gave myself a major headache reading through the Corporea code (forgive me for this, as I'm not a modder and lack the contextual knowledge) to see how it handles this, which sent me on a dive through Forge documentation and old forum posts. I apologize, I wasn't aware of the limitations on determining stack sizes and just how much work is involved in making inventories that hold more than the max stack size per slot.

It seems that the Crystal cube, when updating it's count, finds it's attached spark, which then finds all the other attached sparks, iterates through all the "nodes" (tile entitites attached to those sparks) and if it's a vanilla or forge tile entity with an Item capability, it iterates through all the slots of the inventory and calls the itemStack.getCount() method for that slot, finally adding all the counts together.

My limited programmer knowledge tells me that overriding that getCount method through some facade abstraction might be a much cleaner solution, but I'm unsure if this is possible in the MC modding world, so if it's a faff, then a config setting like you described that can decrease the max stack size to the vanilla defaults would be an acceptable solution, barring whatever performance penalties there may be.

One question I have about that is how the actuator would behave with things that have different default stack sizes, like Eggs, Ender Pearls, Potions, Buckets, etc?

I assume corporea does not compare the capability references it gets from the wormholes and instead probably uses the block position of the tile entity (which is not unreasonable in 99% of all scenarios).

You are correct, it does work this way. One thing that boggles me is how it works with Arcane Archives networks somehow, but that suggestion was more of a "polish" suggestion as it's not crucial to gameplay - one can just limit themselves to one spark per actuator "network".