So I'm still tracking this down, but I've been able to recreate this several times now, just not very reliably. If you set up a chest to receive item A, and then increase the limit to allow it to hold more than one slot, then adding an additional chest set to signal A after the fact will very briefly show the correct amount of items in it with the correct limits, and then forcibly swap all existing chests with item A as their signal to a new channel, and I can't seem to find any way to force it to go back and let me access the items which are now lost in the void. Essentially, it's now on A2, which is empty and set back to a limit of one slot of items.

So I'm still tracking this down, but I've been able to recreate this several times now, just not very reliably. If you set up a chest to receive item A, and then increase the limit to allow it to hold more than one slot, then adding an additional chest set to signal A after the fact will very briefly show the correct amount of items in it with the correct limits, and then forcibly swap all existing chests with item A as their signal to a new channel, and I can't seem to find any way to force it to go back and let me access the items which are now lost in the void. Essentially, it's now on A2, which is empty and set back to a limit of one slot of items.

Edit: Trying to recreate it more reliably now, I've been writing down the channel numbers. It appears that it's not that it's actually changing the channel of the chests, but that setting the item limit lower than the current amount of items contained in the chest will delete all items beyond that amount if you close and then open the chest. So, because every chest defaults to having only one item slot filtered and allowed, trying to add a new chest somewhere to access something which you had meant to set up a buffer for somewhere else will result in the deletion of potentially a lot of items.

Edit Attempt 2: did I misunderstand something about the formatting here...?

the feature to "increase limit" does not exist. at present only one slot per item is implemented.
if you can add more slots of the same item, then it is a bug in my code, resp. a case that has not yet been properly responded to.
the only supported case is, add an other item, this will update all chests with th same id and assing a new key.
reason: the key is calculated by a distinct sorted list of items, if an item existiert several times, no other key is generated.
so, for example, B-A-C results in key A-B-C and B-A-C-C results also in A-B-C.
The main use case for the chest is to define keys then the slots are automaticaly reserved and a new or existing id (if the key already exists) is assigned to the the chest. manipulating the the slot filter is a special case and maybe not yet stable in all cases, as you unfortunately had to discover.
I scheduled a mode where you can customize the filter slots, this means the key will then independ of the filter slots and visa versa, but at present it is a 1:1 assigment.

Aha, that explains a lot, thanks very much. I didn't realize that feature was unsupported, so when I wanted to buffer a larger quantity of an item like belts or modules so I could grab some stacks for my own use I just increased the amount of slots that the chest was allowed to hold. The problem came in when I would slap down a chest somewhere else to use the output of a previous factory as an ingredient and then when the stack limit reset to 1 slot I'd lose all the rest.

With that being the case, I think I prefer keeping a small amount of logistical challenge in creating crafting units with more than one ingredient and so I might just reduce the total number of slots per chest to a maximum of 1, since I have no intention of using the multiple-items-per-chest setup. I've only managed that once by accident anyway, funny enough.

Other than that though, I wanted to say thanks for the mod because I've been having a surprising amount of fun screwing around with it. I tried it out after I got fed up with managing a main bus of like 30 items some of which were only needed in three places scattered throughout my factory unpredictably in K2SE, and I did not at all expect that 16 hours later I'd still be playing and not even reached space yet.

For no particular reason whatsoever I'm having a blast optimizing the amount of space taken up by processing units consisting of six assemblers which use these chests. My best is a 5-input 1-output unit with 6 assemblers in 12x12, and 1 or 2 input factories only consume 9x9 tiles of space for six assemblers. It's been a weird amount of fun, considering the amount of the usual "logistics puzzle" I have taken out of the game by using tons of Surface-wide Chests for everything.

I use the chest in 2 different ways,,
in the mall mit 1 item slot per chest and
in the production with all ingredients in a chest and all out puts in chest + a additional chest to collect all ingredients into one chest

It may seem that one slot is not enough, but it is enough so far before my 15.000 chests ;-)
but sometime you need more as one chest with the same content. The reason ist not the one slot, but the speed of the loader

P.S: The yellow and blue arrows are inserters from my Slim Inserters

That's some neat setup. I've elected not to use the combined/multi-ingredient chests because working out some belts is still fun, it just turns the factory into a series of little connected puzzles instead of one huge one with 90 pieces in play at once.

One question I do have though: is there a way to view a list of the channels numerically or something? Every few hours while playing I'll go to make a new chest for something like "Electric Motors" to connect to the existing network, but it won't connect correctly. Instead it creates a new channel for Electric Motors, and I can no longer make new connections to the old one. Setting the item in the interface causes it to default to the new one. In this particular example, electric motors had previously been numerical channel 59 and now they're something like 163.

The solution is manageable if a bit tedious, I just found every previous place where I was using that particular channel and swapped them all to the new one, but it is a bit weird, and potentially quite problematic if I can't pin down the cause.

I'd love to be able to see a list of all my used channels.

I'm also wondering about priority setups. I'm wondering if there's an easier way to specify that one location should be allowed to input before another. Right now what I'm doing is using at least three channels for a given item. "Item" is what I pull from to use it, "Item + 1 signal" is the higher priority input (like used barrels), and "Item + 2 signal" is the lower priority input (like newly created barrels). This works well enough, it just means that I need to have, somewhere in appropriate range of all inputs and outputs, a series of priority splitters and loaders that do nothing but move these items around. It is somewhat throughput limited though based on how fast I can move items between them though, so it doesn't work as well for some things like copper ore as a byproduct of lead smelting.

I haven't figured out yet why this happens, but you can do a rescan of all chest, see settings. this will generate new Ids for the existing keys.

I'd love to be able to see a list of all my used channels.

There is no benefit to get a list ;-) because you select a key and the channel is assigned automatically. but maybe later.

I'm also wondering about priority setups.

the chest has no priority system. but you can build you own, using circuit logic, therefore you can use virtual signals as a key to have a product more than once. Use 2 loaders with condition which filling A>100 or B <100 into C. to use the items use only C it contains the priorized product. I use the loader from my Slim Inserters, they are perfect for a chest to chest transfer, also for ores or cables. you can scale your throughput, in which you use several chests.

only one collector is necessary for a whole Factorissimo building,
https://prnt.sc/qdjS32FiR1fC

Hmm... two questions actually. Or rather, a question and two different crashes.

First off, how the hell are you putting water into those chests...? How much water is a stack of water? Wild. If I set the "item" signal for a linked surface chest to "water" it actually just crashes my game. Possibly the result of me not having a mod that turns fluids into beltable items?

The mod Kuxynator's Smart Linked Chests (2.0.8) caused a non-recoverable error.
Please report this error to the mod author.

Error while running event Kux-SmartLinkedChests::on_gui_elem_changed (ID 69)
Unknown item name: se-beryllium-hydroxide
stack traceback:
    [C]: in function 'set_filter'
    __Kux-SmartLinkedChests__/modules/Chest.lua:315: in function 'setFilter'
    __Kux-SmartLinkedChests__/modules/ChestGui.lua:351: in function 'fnc'
    __Kux-CoreLib__/lib/EventDistributor.lua:157: in function <__Kux-CoreLib__/lib/EventDistributor.lua:151>

Second, I also crash when attempting to use the "Rescan" command. When I have some more time tomorrow I'll have to mess about and see if I can figure out why.

The mod Kuxynator's Smart Linked Chests (2.0.8) caused a non-recoverable error.
Please report this error to the mod author.

Error while running event Kux-SmartLinkedChests::on_runtime_mod_setting_changed (ID 61)
__Kux-SmartLinkedChests__/modules/Chest.lua:579: attempt to index field '?' (a nil value)
stack traceback:
    __Kux-SmartLinkedChests__/modules/Chest.lua:579: in function 'rescan'
    __Kux-SmartLinkedChests__/modules/Chest.lua:585: in function 'rescan'
    __Kux-SmartLinkedChests__/modules/Chest.lua:603: in function 'fnc'
    __Kux-CoreLib__/lib/EventDistributor.lua:157: in function <__Kux-CoreLib__/lib/EventDistributor.lua:151>

LOL the water is "Solid Water" using Omnifluid. the first crash is already fixed in my development version.
OK, the rescan should not crash, i will have a look for it. .... i have made some changes, so lines moved. I can not identify the problem by th line number. please try the next version, as soon as it has been published.
please do me a favor, for a new issue always create a new topic.
--EDIT
OK, the second crash depends from the first. water is not an item. so already fixed.
to avoid the crashes, do not choose liquids ;-) in the next version I prevented this.

Lol, thanks. If I encounter a new crash at some point once the next update is out, I'll be sure to make a new topic.

I figured it had to be something weird like turning liquids into solids. I'm pretty happy with just using a barreling setup. I'm still getting some of the logistics flavor, but I can deal with hundreds of inputs and outputs without getting overwhelmed trying to figure out what I should or shouldn't belt, or dealing with things being starved intermittently at certain spots along the belt because of throughput limitations.

Playing like this, if I'm low on X I can just make more of it faster and drop it straight into the same exact setup.

I don't think the rescan should be related to liquids, because I was doing it separately, but I'm happy just to try again when the next one comes out. Cheers~

nevertheless the rescan crash is related to the fluids because I use item_prototypes(name) and that goes wrong because the fluid it not an item.
besides, i looked in the code and not just guessed ;-)

uodate is out, took a little longer than intended

Excellent! Thanks for the update, no rush here. I can attest that both use cases mentioned above are working great.

I can both select a liquid from the menu (which will just leave me with an un-keyed chest because it selects nothing instead of crashing) and I can rescan successfully. I got a report of 1591 chests with 211 used link-ids and 212 different filters. Hadn't realized I was using quite so many!

I have currently 15.000 chests in K2 midgame ;-)