I am fully aware that this changes a core premise of AE2, but I'd still like to ask for it.

Describe the feature

Make channels "smarter", by having then consider side-cables when existing ones are already saturated, "spilling" over to those extra cables.

Example, consider the following scenario;

(16 machines, both cables are directly connected to a controller behind me)

Here, the channel resolution method (if i understood correctly) first deduces the shortest route of every machine these to the controller, then it starts "accepting" channels for each of the first 8 machines directly to that cable, until the cable is saturated, after which the resolution mechanism stops. It didn't even consider the adjacent cable.

In a potential new channel routing algorithm, the algorithm will restart "routing" again after it finds a potential channel blocked by a now-saturated cable, and instead marks that cable as non-viable in the new routing "cycle", next it'll find that other cable, and correctly route the remaining 8 machines.

This repeats until stalled (where the input state of the algorithm matches the output, idk if that's possible, but i'm including it anyways), until all cables are saturated, or when all machines are routed.

Reasons why it should be considered

This makes channel-routing easier, "simpler", and quicker to understand as a problem of capacity instead of a problem of specific routing quirks. The current resolution method was obtuse and not easy to understand or wrap my head around (or others, for that matter), and it doesn't intuitively match (for example) how real-world Ethernet routing would work, on grand scale, which overflows into "side-routes" when the main routes become saturated. It also doesn't intuitively match the idea of water and piping, which floods into side-rivers and side-pipes whenever the main pipes/rivers are congested.

The current approach also takes server performance into account. We cannot really use an algorithm, which tries every permutation until it finds the optimal one. It simply offloads a bit of the processing to a player to avoid running into absurdly expensive loops or even deadlocks under some conditions.

Also in terms of real life counterparts, it's like (parallel) SCSI with pass through connectors and device ids. Feel free to try and attach a SCSI disk to multiple controllers. No idea what happens when sharing a bus in this case. And assuming you can still get working ones.