Now I was half-way into an essay justifying an "interface module", but the more I tried to nail it down the more it felt like unnecessarily fuzzying things up. So here's an alternative idea: to make integration easier, don't require people to have their own full item implementation and so on.

Instead, allow registering a module by specifying a texture (the overlay being used) and a constructor callback (of the module class). Then internally create and register a new item, and create a provider for it using the specified constructor. Probably return the created item to allow further initialization of it (e.g. set name, change creative tab, ...).

Obviously, this should be called in the preInit phase (since that's when items should be registered).

Sounds reasonable? Am I forgetting something?

I keep coming back to the idea of a "serial port module" or such after all... something that would work similar to driver system in OC, i.e. allow defining an arbitrary serial interface for a given block position (in front of a serial module). With the key difference, making it closer to the above, that there could only be one single driver per block. No auto-merging. At least not in TIS-3D itself. This would be to enforce separate "protocols" for each and every block that would support this.

To boil it down to one key point, that I had trouble formulating until now: regular modules support one protocol, generally on multiple blocks with common functionality, e.g. redstone I/O, whereas the serial port module would support multiple protocols, so also multiple blocks, but each with completely distinct functionality.

In implementation terms, when providing access to an interface in some way (e.g. inventory interaction, reading slot contents in some way or such), that would go into a separate module. When providing access to a specific block, e.g. the command block, note block, progress from the furnace, that would go into a driver for the serial port module.

One of the main reasons I'm still reluctant is that this would be an utter pain without proper documentation. Each mod using this API adding a tab to the manual just for one or two such protocol definitions seem... suboptimal. Possibly a custom content provider and allowing registering explicit protocol definition pages or so.

And done. Available via the serial API now; in-game documentation strongly encouraged by demanding a link to add to the serial protocols list in the actual interface for providers.