Changing the return type to long is insufficient, but required. (unless you're really lucky with tests?)
You must also cast the long to int, as some random tests expect the overflow value.

The c# solution is currently not solvable without this realization.

After some investigation and re-reading what g964 was getting at - I've learned the solution is correct and consistent. Previously I was using format but on a cast, not leveraging actual formatted display of floats. (I knew I was doing something foolish)

For those stuck on this, scratching their heads - I would encourage you to read up on this:
https://users.rust-lang.org/t/formatting-floats-and-rounding/10235

Thank you for the kata, I learned something new.

I am still confused, inspite of your thorough description.
One of the basic tests is as follows; the raw sell value is 6407.6, but 6408 is expected?

l = "GOOG 90 160.45 B, JPMC 67 12.8 S, MYSPACE 24.0 210 B, CITI 50 450 B, CSCO 100 55.5 S";
sol = "Buy: 14440 Sell: 6408; Badly formed 2: MYSPACE 24.0 210 B ;CITI 50 450 B ;" ; //raw sell value is 6407.6; not truncated
do_test(l, sol);

This lead me to round, in spite of the instructions. Afterwhich I was met with this random test:

l = "CAP 15 89.3 S, APPL 67 45.5 B, CLH16.NYM 24.0 5.5 P, CITI 50 450 S";
sol = "Buy: 3048 Sell: 1340; Badly formed 2: CLH16.NYM 24.0 5.5 P ;CITI 50 450 S ;"; //Raw buy value is 3048.5; raw sell value is 1339.5
do_test(l, sol);

These values seem to be rounded (inconsistently) as well, not trucated.

Perhaps (most likely), I'm doing something foolish here. Any insight would be appreciated, as I've attempted format! and write! as well as rounding to no avail.

Thank you.

Thanks, this was a blast!
Bobby tables would approve.

This is an existing problem documented (much better) by iago.passos. Marking as resolved to avoid duplicated issues.

I may be mistaken, but it appears the rust solution has some issues.
A portion of the tricky tests return the following error:
With n = 17700847248605297701
Expected 17700847248605297700 but got 84 at src/lib.rs:50:9

I believe 17700847248605297701 in base 84 is correct:
1:1:1:1:1:1:1:1:1:1:1_84 (11 digits), meaning the accepted solution (perhaps sometimes) returns n-1 in cases which it should not.

finally got it!

👍

I was so focused on maintaining consistency across the different parts of the kata in the series, I misinterpreted your first point.
I've updated accordingly.

As an aside, I did end up making the input i32, not u32 - as traversing negative heights (valleys) should behave the same. The output is u32 as you recommended, as that should never be negative.

I'm wrong, the kata defines heights as 0-9, so I shall make it unsigned.

I agree with each of your points and have adjusted the translation accordingly. The inclusion of option was a carryover from the prior two versions IIRC. In any case, it doesn't belong and was updated to u32.

Thank you for taking the time to correct and improve my submission - I will keep the points you've raised in mind for future translations and kata.

Rust translation

Available for review.

What is not working specifically, can you provide an output?
Is your local version of python the same as what you have selected on codewars?

Thanks - I was not aware.

Updated with
Note: Input might not have an even number of divs.

Thank you again for your help.
This has been corrected.