It's just the opposite.

I must have misinterpreted the kata then, given by the examples it looked like it wanted the solution with the pairs the least distance apart...

No, but when you reach the 8 of the pair (in your example), the [6, 4] pair wasn't even read. That's what parsing from the left means.

This is the description I'm seeing...

sum_pairs([10, 5, 2, 3, 7, 5], 10)

^-----------^ 5 + 5 = 10, indices: 1, 5

^--^ 3 + 7 = 10, indices: 3, 4 *

* entire pair is earlier, and therefore is the correct answer

== [3, 7]

is [3, 7] wrong in that case?

the examples have shown pointers with possible solutions, I must admit it looked misleading seeing the second example with the same-length pairs

No, you're wrong, that's not what the kata asks, [2, 8] is the right answer.

this solution would not work with this case if you go for the shortest distance:

print(sum_pairs([1, 2, 10, 7, 5, 8, 9, 3, 6, 4, 12], 10))

actual: [2, 8]
expected: [6, 4]

The examples given have random order of numbers. The requirements say to return the pair with the shortest distance, this solution does fulfill that requirement.
It's a very nice solution regardless.

It took me a few min to realise that its a good one haha

Dont mean to burden with this simple operation but I'm left a bit confused on the !(weight % 2) can someone shed some light on this...

Had the same problem. With plus/minus, you shouldn't modify the existing class, but instead return a new one (which is stated in the description).

my test cases are constantly crashing with free/malloc issues... x_x

I suppose given that this is a 8kyu kata a division by zero special case would be too much, nice beginners kata though.

consider this:

a = [1,2,3,4,5,10,11,12,13]
b = [1,2,3]

a = [1, 10, 11, 12, 110, 111, 112]
b = [1]