Actually, Borda calculates a vote count for each candidate which seems not to rely on the seat count (the value of the "-s" option). I tested this for all votings with seat numbers from 1 to 4. In all cases the calculated vote count did not change depending on the number of seats. This is also expected behavior if you look at the definition of how Borda works: http://www.openstv.org/borda-count

What I can tell so far is that Borda seems to order the candidates according to the vote count. A larger vote count means "better" or higher position. The selection of "Winners" is then performed by taking the first n (n=number of seats) candidates from this ordered list.

With respect to the example I posted this means we would end up with an ordered list like this:

1. Filebox http://competition.meetmeego.org/submissions/66 | 514
2. OMWeather http://competition.meetmeego.org/submissions/47 | 495
3. MIR Translator http://competition.meetmeego.org/submissions/24 | 343
4. KhtEditor http://competition.meetmeego.org/submissions/60 | 240
5. TxPad http://competition.meetmeego.org/submissions/5 | 227
6. QtWeather http://competition.meetmeego.org/submissions/45 | 224
7. Audiobook reader http://competition.meetmeego.org/submissions/27 | 195
8. Proximus http://competition.meetmeego.org/submissions/38 | 162
9. stockona http://competition.meetmeego.org/submissions/25 | 136
10. ItemNoTe http://competition.meetmeego.org/submissions/83 | 90
11. Vcounter http://competition.meetmeego.org/submissions/70 | 66

This means there is no need for "iterative" or repetitive election runs like when using one of the *STV methods. The ordering of entries is solely by vote count which is not affected by parameters like number of seats.

So far... I hope I could present the technical and mathematical details unbiased and that this helps for the further decision making. As already mentioned earlier I am very much trying to be objective and not to imply that one solution is better or worse than another.