discussion: inconsistent cost of belts/pipes

the way that belt/pipe costs are calculated is inconsistent; and it depends on how many cuts the pipe/belt has.
here's an example I just ran into copying and pasting bakeries:

here the belt enters normally, no connector: (3 parts 0.6 unity)

here the belt has a connector and continues on: (3 parts 0.6 unity)

here is the same belt connector as the one above, copy and pasted, (first half): (2 parts 0.1 unity)

and again (second half): (2 parts 0.1 unity)

in short, 2 parts 0.1 unity + 2 parts 0.1 unity != 3 parts 0.6 unity. I doubt this is by design, but I've noticed:

• when building medium-length pipes/belts, I've found that it's actually cheaper (on unity) to split the pipe/belt into 2-3 length bits -- though it often times costs an extra part.
• for long pipes, it's usually a huge savings (on unity) to merge the medium-length pipes/belts cause the unity cost doesn't scale linearly with length (merge by connecting a pipe next to the cut and remove pipe which removes the connector, which makes it one long pipe)
• for small cut and paste of buildings, each copy and paste is very cheap (on unity), but often times costs an extra part -- which does add up to be tens to hundreds of parts lost over time... :)

I know it's not that big of a deal in the grand scheme of things.

personally, I'd prefer:

• all belts/pipes to be automatically merged
• parts cost to actually be a real number in size, even though everything displays a rounded-down integer (so two transports cut into a thousand pieces (which wouldn't happen if they were automatically merged), would cost exactly the same.
  • for example, if I build two transports that cost 3.2 cp1, both of them say they cost 3 parts, but on the 5th transport, it probably still says 3 parts, but the stats on the right will show it as 16 parts less.
• unity costs to be calculated as a log of its length + some base amount calculated (probably as a log of its parts cost).

after writing the above, I decided to try out to see if I can use this effectively. turns out:

• for t1 pipes, the magic number is (4 cp1 0.1 unity). anything more than 4 cp1, costs 0.5+ unity.
• for t1 belts, the magic number is (2 cp2, 0.15 unity). anything more than that costs 0.6+ unity.

now I decided to revamp my current construction project and build the belts in small sections to see what the cost difference is,--seeing how much unity I can save with that technique. (here's the save file if you want to try it yourself: saving unity the hard way.save)

the belt I'm building for the bakery costs full-size (31 cp2, 4.35 unity), whereas if I break it up into small bits, it costs 16x (2 cp2, 0.15 unity) + (4 cp2, 0.75 unity) ie, (36 cp2, 3.15 unity). so, by breaking it up, I can save 1.2 unity; at the expense of it costing 5 more cp2...

though, I started to wonder if indeed the costs are actually all floating point values rounded, so I started to notice rounding now. here's a related thing regarding rounding: the QUICK DELIVER button shows a different value than the tooltip (if I build it and look at the difference of unity, I see the tooltip is correct)

the belt dialog (2 cp2 0.1 unity):

unity tooltip (0.15 unity):