While translating the kata, the question that arose back when I first solved it reared its ugly head again:
The builder is entirely capable of calling a base coffee type twice in a single chain, and it is not specified what effect exactly this should have.
Accordingly, it is never tested for, though a correct solution should handle such a case, and I believe we should be promoting correctness wherever possible.

Imagine a case like Builder().cubano().with_milk(1.0).americano()
Note the trailing americano(), a new base type. From what I can see, there are 3 different choices on how to handle this case:

1. A trailing base type "resets" any previous build process. Here, these two expressions are equivalent:
   Builder().cubano().with_milk(1.0).americano()
Builder().americano()

2. A trailing base type simply adds its attributes to the existing build proceess. Here the expression
   Builder().cubano().with_milk(1.0).americano()
   simply adds the base 0.5 of the "americano" to the existing ingredients, resulting in a coffee with 1 brown sugar (cubano) and 2 milks, 1.0 (with_milk) and 0.5 (americano)

3. Any base type following the first base type call is invalid. So as not to introduce error handling into this kata, any trailing base type call would simply be ignored as a no-op. These two expressions are equivalent:
   Builder().cubano().with_milk(1.0).americano().with_sugar("Stevia")
Builder().cubano().with_milk(1.0).with_sugar("Stevia")

Option #2 is what the reference implementations (and most user solutions) do in C# and Rust, and I assume in other languages as well, however this is purely incidental. When authoring my own solution, I wasn't aware the tests simply wouldn't produce such cases, and opted to go with option #1 for lack of any specification.

Additionally, the spec does not mention the behaviour of first adding milk/sugar, and then calling a base type: Builder().with_milk().americano(). This needs the same considerations as above.

My proposal would be to actually decide on a proper spec, describe it, and modify existing translations to implement and test them while there are only 3-4 languages currently implemented.

Python translation ready for review (see notes in translation discourse)

Some language versions doesn't have random tests.

"Turn a trivial math problem into a program" is neither new nor interesting kata idea.

Author solution is incorrect ;-)