The current interface covers a vast amount of functions with some of them interfering each other or having non obvious side effects.
This covers things like providing access to the full network by default by once a single slot is configured, it acts similar to a simple chests. Or having patterns producing the same itemstack as the one defined to keep stocked can have some unexpected side effects.

The goal would be to make each new block simpler in terms of code and hidden features. Especially when considering adding support for fluids in crafting or other changes like a more sophisticated blocking mode.

ME (Item/Fluid) Interface (reuse)

Keep the current behaviour of acting like a garbage collected chests, which can stock some items. Either from only storage or also crafting them. Remove the pattern handling and network inventory access.

Expected use case would be to simply act as an interface for other mods to return their items to or as provider for a few itemstacks.
Returning crafting results would still be a valid option, but not required.

Separation into an item and fluid variant must be kept.

ME (Item/Fluid?) Pattern Provider (new)

Replaces the the current pattern functionality of interface and interaction with molecular assemblers or other machines.

Additionally it should act as return channel for the assembler/machine. This would overlap with the interface to some degree. Limiting it to only allow recipe outputs back would be an idea. However this could have issues with optional outputs from machines as there is no way to anticipate them.
This is especially true for chance based ones. If a players defines a pattern like iron ore -> iron ingot + nickel ingot, the system might pick this recipes to craft nickel ingots. Even if just has a 5% chance to produce one.

Further it might be problematic with stuck items. It should not have simple slots as part of the GUI to allow a user to interact with it to avoid duplication for the normal ME interface. Yet it needs a way to indicate some items are stuck because there is no space in the network or similar. Might be solved by simple readonly slots/tanks, allowing a player to see the problem but not dump their inventory into it. Additionally with less functions overall, we could have a meaningful effect on the model itself.

Ideally it should be separated into an item and fluid variant. With this mainly applying to the recipe output.
Each variant should still be able to export recipes like item + fluid -> item into the adjacent machine (or corresponding fluid output). This might result in some edge cases like emptying buckets, but there will always be the option to return some or all outputs to a normal interface

ME Storage Provider/Accessor/inverse storage bus/whatever (new)

This would replace the subnet functionality and maybe a few edge cases needed for autocrafting.
Unfortunately this cannot provide access to the whole network for external consumers for various performance and game design reasons. So it would feel a bit odd to exist as very narrow use case in AE2.

This might be offsetted by allowing some special interaction with pattern providers to dump all ingredients into them regardless of being an item, fluid, or whatever else is possible and then use a subnet to distribute it across the correct machines or sides of one machine. In return this would pattern providers a bit more complicated, as they would have to deal with basic item or fluid handlers as well as the whole ME inventory access.

As it would provide access to the whole network and to cover the autocrafting part, having a combined variant for all storage channels is feasible. The actual storage interaction would still be limited by the actual item or fluid storage bus.

Mostly done. Separate network interface will not happen as it is too specialised. Maybe as explicit config option for the interface itself.
However like other changes this will be handled with new issues.

I really like the "inverse storage bus" because this would also allow to use the "garbage collected chests" with a storage bus

I could see how a new block could act for accessing network/making subnetworks, but splitting it further seems unnecessary.

FE:
If you put the interface on the Block that allows item inputs from one side only, you can now put permanent supply items and recipe on top of it at even push the items right back into the interface by some kind of pipe.

After the change you would have to place two block (New Interface and Pattern Provider) and than pipe it out of them, not even know how you would go with blocking mode than (2 chests? with limiting of some sort). Current capabilities of interface allow you to do lot of things with great ease.

I wouldn't mind having these two block if later you could make something like 'Advanced Interface' that would have all the functions of current one but I'm not sure how enjoyable would it be to re-do the network for an update that you would have to gate behind some meaningful recipe so that people won't get to it immediately anyways.

I do not think this is a particularly important use case. It is pretty much limited to machines which are limited to an input on a single side and can actively pull items from the adjacent inventory. Once one of the condition no longer applies, it already would not work. Either it needs a hopper or pipe to compensate for the single input side and no active pulling. Or it supports multiple sides and then it is not an issue at all.

Also it would prevent players from using the same interface to craft and stockkeeping via crafting, it can randomly stall depending on the interface deciding to keep the items for themselves and never finish the crafting job. And this can happen randomly through a bunch of different conditions. As well as other edge cases like a interface with all slots configured to stock something will no longer accept any result from an adjacent molecular assemblers.
So it certainly will allow us to do a couple QoL changes without having to fall back to error messages as part of the UI.