Not bad kata. Imho would suggest removing superfluous elements from description to increase clarity and make it more about solving the kata than reading a story.

Also would suggest either telling warriors to use whole numbers rather than incrementing anything by fractions like 1/2 or 1/3rd. I was getting errors when I didn't use whole numbers for my math even though it was the same math as when I used fractions.

Common Lisp translation, please approve / reject.

All languages should use floating point comparison

Ruby 3.0 should be enabled.

the description is far from good...:

• especially convoluted about the first rule to break ties (why not to say the... "obvious", to make the things clearer?)
• examples at the end have to be given in code blocks, to make clear what the separators are, when there are ties (=> ", ")
• the description is actually wrongly worded about the final point of tie breaking:
  • first sub-point clearly tells the ties stands, but doesn't say to actually add "(ties)" at the end of the string (the info must be given there, not after)
  • second subpoint is clearly wrong, because it suggest the tie has to be broken while it actually isn't, on the coding/user side: it's only about adding another suffix to the string. This had to be rewritten properly.

JS:

• the tests need to use chai.assert.deepEqual, not assertSimilar
• the sample tests are close to useless, since they provide no case with ties/jump-off
• no fixed tests in the full test suite

python:

• the sample tests are close to useless, since they provide no case with ties/jump-off
• the sample tests should be the same in all languages (to resolve the following point as well)
• the description is fully doubled for python: that's useless
• the initial solution in python contains a JS comment (which makes it invalid in python...)
• no fixed tests in the full test suite.

Is there a reason this isn't being tested within some tolerance? I've solved this on Python without issue, except that for ~1-5 random test cases I'm off by 1/1000 which makes the rounding break the other direction(e.g. 0.444 => 0.44 vs 0.445 => 0.45).

Considering this is an 8-kyu challenge with no obvious solution, it should utilize the V2 test suite's approximation.

Need example tests to show what's going on :)