Since this mod is inspired by TIS-100, made by Zachtronics, I got an idea for a multiblock inspired by Exapunks, also made by Zachtronics.
The multiblock is composed from a controller, nodes and links.
Controller works just like TIS-3D controller, but instead for this multiblock.
Nodes provide storage capacity, exactly 256 bytes per node, they also hold files, but since they are virtual, it doesn't matter where files are.
Links are like an EXA, in that regards it can grab, drop files and transfer information, it works just like an infrared sensor, but is a solid block instead of a face.

Internal storage structure
Your total capacity is determined by the number of nodes.
Each file has an ID and any number (limited by your total space) of 16-bit numbers. (that is 128 numbers, per node)
You can have infinite amount of files (or make it, that one file takes few bytes from storage).
Using links you can grab files, so that you can read/write to them. One file cannot be held by mutliple links and one link cannot hold multiple files.
Every link points to a file. When you grab a file it points to the first value (if any).
Everytime you read/write to a file, you move link's pointer by one, wrapping back to the first value, if you get at the end of the file.
If the link doesn't hold any files and your read/write to it, it behaves the same as nil register.

Link protocol
All commands to the network are passed one by one, the same way you would command RAM, but since the link is a infrared like thingie, you must keep some kind of a structure. You first write an operations ID and then any arguments if necessary.
Command ID 0 - grab file, it takes one argument which determines the ID of file to grab
Command ID 1 - seek file, it moves the link's pointer by the argument's value, it wraps around the file
Command ID 2 - read file, it reads the current pointer and moves it by one
Command ID 3 - write file, it overwrites the current pointer by the argument and moves the pointer by one
Command ID 4 - append to file, it appends the argument after the current pointer, which it moves by one
Command ID 5 - remove from file, it removes the number at the current pointer
Command ID 5 - file size, it tells you how big the file is
Command ID 6 - pointer pos, it tells you where the pointer is
Command ID 7 - file id, it tells you what file do you hold
Command ID 8 - pointer to last, moves the pointer to the last value
(Command ID's are only examples of many possible commands, we can have 65536 commands after all)

Examples - IR means the direction your infrared is at
grab file 111 and read first 3 numbers
mov 0 IR
mov 111 IR
mov 2 IR
mov IR acc
mov 2 IR
mov IR acc
mov 2 IR
mov IR acc

or since infrared stores packets, you can do this

mov 0 IR
mov 111 IR
mov 2 IR
mov 2 IR
mov 2 IR
mov IR acc
mov IR acc
mov IR acc

Why? and final words.
This multiblock is a jack of all trades in some ways, it is a glorified RAM, that can be expanded at will, but comes at a cost of slower access times. Below is a program that read address 777 from this network regardless of where in the file you are. (it expects the right file)

mov 9 IR //get to the end
mov 1 IR
mov 1 IR //get to the start, could be substituted by having the address increased by 1
mov 1 IR
mov 777 IR //get to the address you want (or mov 778 IR, if you want to remove the double mov 1 IR)
mov 2 IR
mov IR acc //finally get the value

Or it can be used as a way to store checked strings (for example for checking terminal commands), since the pointer moves itself automatically, you don't need to remember where you left off. Just read repeatadly.
Or it can be used as a sequencer, but with support for infinite numbers, but bulky.

Basically, this network can be useful, but won't replace another means of doing things, unless you really need this capacity for things. (Large memory, quick and dynamic indexing of data, etc.)

Hopefully, you understand what I mean.

update i made part of one
i designed a "flower" that uses alot of execution modules and is able to route a "packet"? using the first 4 bits (and in order to route it based on the full 16-bits i would need 16 more of those (because i only have to route the upper byte, then normal RAM/ROM can handle the lower byte)

i think i personally would like a larger storage method
also mabey if it had a decently expensive cost to craft it would be perfect (so that i dont have to design and implement my own massive IR/RAM/Rom module mess of a cube)

after playing EXAPUNKS, tbh i want exapunks as a seperate mod
and just add a optional TIS-3d integration with say... infared (probally as a Hardware Device, and upgrade EXAPUNKS to 16-bit)

The SWIZ command in EXAPUNKS need to be changed though

the swiz command is entirelly possible
since 16-bit numbers have 5-numbers
and the max of a 16-bit is 65536 meaning that we can have 55555, therefore swiz fits pretty well
the only change is it is 5-number instead of 3-number

i keep considering making a execution module that runs on shenzen io instructions

+ 16-bit
+ all the funny shenzen io syntax @, +, - (the main reason why adding shenzen)
! every side is XBus (mabey implement a wrench that switches XBus to simple io)
! synced to step (1 ins/step, could probally decouple it from step if i wanted, and make `slp` usefull for "realligning" with the execution)

I'm afraid this feels somewhat out of scope, in particular since I already struggling to maintain the mod. If you need additional APIs to make this an extension/compatible mod, I'd be open to discussing said additional APIs however.