Now that we have basic fluid support we should start thinking about how to implement crafting in the future. Currently it is limited to ItemStacks, ideally we would support any storage channel.
My suggestion would be to gather requirements and add needed API changes into rv6. The reason is that i personally don't want to release another API breaking rv before 1.13, and as it looks right now 1.12 will probably be around quite a bit longer. I'm putting this here to get input from add-on developers and start a discussion.

One thing i think the the storage channel needs to support is to be able to interact with external inventories of it's type. This will be needed for interfaces to push ingredients into machines and extract the results.

Technically we only need an export for crafting. Interface won't ever pull anything and it's just coincidence/convenience that assemblers push into adjacent inventories, which interfaces happen to be.

It is also the easiest option, to avoid running into many issues compared to export and import functionality. In this case interface would become even more "one block solves everything" machines as well as the GUI/TE needs to support every storage channel out there.

It needs a way for the GUI to tell that it couldn't empty the pushed items. So it needs to display itemstacks, fluid tanks, gas tanks, emc values, thaumcraft stuff, and whatever else might happen.
As well as handle dropping them somehow when destroying the interface.

Further it requires the pattern terminal to handle every IAEStack out there and some way to convert between them. Using some special itemstacks won't really work because it would make these items uncraftable for other cases. And e.g. buckets are still valid ingredients for normal recipes.
So the whole change would also depend on a GUI refactoring happening before.

Sure, technically for the interface only pushing is required. I was thinking of something like this:
IMEInventory<T> getInventoryAt(BlockPos pos, EnumFacing facing)
Maybe needs another method to support blocking mode.
GUI is the really hard part here. While it's ok for now for buses and interfaces to be specialized, the pattern terminal would need some kind of way to specify ingredients of different kind of storage channels.
This PR is about how we would have to change IStorageChannel to support this (if possible) to prevent additional API breaks pre 1.13.

Well, I'm definitely for a RV6 release in 1.12.2. It would allow me to get things more in line for 1.13 for Wireless Crafting Terminal, Thaumic Energistics, and ExtraCells. This would make porting easier for myself and other addon devs as we would then only have to worry about adapting to vanilla/forge changes. I'd like to hear from Mordenkainen and bdew as well.

There will definitely be a RV6 for 1.12. The question is if we can do without another RV before a 1.13+ release (mind, stable forge for 1.13+ may well be a year away - they are planning to do basically everything from scratch). That's the reason i want to kind of brainstorm API changes before we go to beta.

I know, that's why i left it out. Generalized crafting should be possible to implement with the current interface. The patterns themselves may need some adjustments, i'll have to look into it.
I'm perfectly ok with buses, interfaces and terminals being limited to 1 storage channel. But for crafting the interface needs to be able to push multiple types (but still accept only its primary type), ideally it wouldn't care about the storage channel used. And it has to be possible to create patterns with mixed ingredients, this is the biggest challenge from an GUI/usability standpoint.

Nonetheless, we decided to leave it for now and go for an opt-in approach by adding additional registries when needed.

I would almost lean toward not worrying about import, export, interfaces, or even the pattern terminal.

At a deeper level, the first step is the crafting system being able to process a pattern that contains non ItemStack AEStacks. How those stacks get into or out of the system is the responsibility of the creator of that IStorageChannel. Same applies to creating patterns.

Each AEStack identifies what storage channel it "belongs" to, so updating the crafting system to be able to read the stack from a pattern, figure out the appropriate storagechannel and run the simulation (or job itself) seems within reach and would at least get the core functionality there.

I can see expanding the interface to handle fluids, but would probably make it so that any mod dev that needs something else must supply an appropriate IPatternProvider/ICraftingMedium that can handle their specific AEStack (and others if needed for the specific case). The same applies for import and export busses.

I think the current API mostly covers mods that need to add thier own AEStacks, StorageChannels, busses, custom patterns, and crafters. What we lack is the ability for the crafting subsystem to handle those AEStacks.

Just extending the crafting subsystem to be able to check avail quantities, pull those AEStacks from the approp StorageChannel, and send them off to ICraftingMediums would close much of the gap.

Longer term a more unified way to do busses and interfaces would be nice, but in the short term I think all the tools are already in place for mod devs to handle those on their own.