Arguments in favor

• This can technically be done by using a wrapper object that redirects the calls based on what face is returned.

Arguments against

• This is very useful for blocks that want different input and output slots.
• The current system allows for much more flexibility, with not extra work for the mod author.

Arguments against:

• This can be useful to differentiate between input and output machines, but you might want to consolidate them into one method: getType(EnumFacinG)

Thank you for the suggestion @asiekierka. I like the idea of replacing it with a new Type. That will make things much nicer.

Arguments in favor

• A more clean approach would be to provide it as two capabilities for input or output. Maybe a third for both.
  You do not have to do something like hasCapability(Tesla, side); getCapability(Tesla, side); if (cap.getType() == INPUT) doStuff()} just hasCapability(producer, side) and can already abort at this level without any further checks.
• You never ever need a consumer and producer for the same operation, except if you want to loop energy around. Which would be stupid.
  Otherwise you either want to extract (x)or insert in the same operation. Even when considering a battery, you still want to either store a positive balance or extract some to resolve a negative balance. (There might be multiple operations per tick, but they are still distinct)

This is very useful for blocks that want different input and output slots.
The current system allows for much more flexibility, with not extra work for the mod author.

Not really true, it can already be done via capabilities. Capabilities would also allow different input/output sides. And even be more flexible because you can have different tileentities share the same handler and still have different side awareness per tile entity. Actually even more flexibility and easier, as this cannot be achieve without an additional wrapper implementing the handler between the tile entity and the shared handler.

Arguments against

• Completely dropping them without an alternative (different capabilities etc) is probably not ideal.
  While it can be trivially solved by letting give/takePower simply return everything back when disabled with mostly no performance issues on the API side. (But there might be some, should calculating how much should be inserted/extracted be performance heavy for the mod itself).
  But anything using some information about it. Like a debug tool which could display the side awareness could be difficult, as it has to abuse the take/givePower. This also raises the question, if something specific for information retrival should be part of it. Say not just report how the sides are configured in terms of input/output but also things like throughput on a single side. Or whatever else.

I think sided-ness should be handled by the capability provider. The interface itself can have something like isInput() isOutput(). A block can return different instances of the capability if it wants to have separate input/output sides.

Merging #6 and #7 into #10