An example, lets have a system with one sink accepting 100RF/t and connect a single source. The system will drain that source for 100RF/t and feed it to sink, everything works fine.
If you connect second source, the system will drain 100RF/t from each (for total of 200RF/t) but feed only 100RF/t to the sink, wasting other 100RF/t.
Connecting third source will make a total drain of 300RF/t (waste of 200RF/t) and so on.
The amount of sinks does not affect the bug.

On image the cell is set to accept 100RF/t (and it does) but EnderIO thing is sending 500RF/t.

Is the power being lost or is it just buffering up in the kinesis pipes (which is the intended behavior)? In other words, if the source has 100k RF, when all is said and done and the power transferred, does the destination receive all 100k RF or is any lost?

Yes, but since buildcraft is switching to RF power, I think it should work like RF systems, giving the ability to store energy, that currently is impossible, since extra power that goes to pipes is wasted unless you connect only a single source, and sice the only possible source pipe can accept 320RF/t that is the limit for whole system.

@hubertnnn - We explicitly made the decision to go for what we call "MJ over RF". Also, there are Emerald Kinesis Pipes which accept 2560 RF/t.

BuildCraft will never have a builtin lossless energy storage system. You are free to use the ones other mods provide, however, expect to have to plan ways of powering them to make sure you are not wasting your engines' input. Like a real power system - if you put something in it, it won't just magically come back.

@hubertnnn my addon BCA has kinetic energy buffers that you can use to store power, powerloss can be enabled/dissabled in the config as well as the powerloss each tick

@smbarbour - He said it drains it, so it does probably lose it.

However, the behaviour here is arguable.

Well, in the screenshot, he's using an infinite capacator, so it's hard to say.

Just tested it with energy cells, and its lost. Target gained 52880 RF and both sources lost 53360 for total of 106720 RF

@hubertnnn - The problem here is a design issue: this is an edge-case. Most people will use engines to power their machines. Do we want the energy network to automatically adjust to the power usage, or do we prefer people manually maintaining the energy system like was the BC tradition?

Any verifiable loss of power within pipes not due to explicit removal (wooden pipe perdition for example) has always been considered a game breaking bug. After taking into account buffering actions by pipes of course.

A bug like this makes the entire system suspect and impractical.

At the time that pipe loss over distance was removed, a multitude of such bugs were encountered and fixed.

If the system has too much power, that should have a negative impact on the operation of the engines, but the pipes should never just throw away power.

This will be harder to fix than I hoped.

Asie, the problem isn't transferQuery. The problem is on the other half of the logic. Pipes are supposed to query for more power than they need, but they are supposed to stop accepting it once the buffers are full.

If you ensure that actually moving power around is 100% lossless, then this bug goes away regardless of how much power is asked for on the request channel. That's how I fixed it last time I found bugs like this.

Though I could have swore transferQuery was already a finite value that split evenly at junctions.

It's actually fixed.

It's actually fixed!