But then you have 2 times more vowels to check, so, all in all... That's just about mircooptimization, that doesn't change the time complexity. You generally don't care about microoptimizations as long as you don't do useless stuff.

Everything works now.

I also tried double precision floats in your Floating-point Approximation(II) kata. It was not enough to change the default precision format. For some reason, it was also necessary to change the provided trunc function:

(defun trunc (x)
    (/ (floor (* x 100.0)) 100.0d0))

I don't think you need to update that kata because floating-point errors do not accumulate too much there.

Modified. I didn't add this line in my first tries to the good place...
Once again lots of thanks for your patience!

Before publishing I tried my solution with your proposition but I didn't see any difference in the results so I didn't take this modification for the definitive reference solution. To be on the safe side the results are accepted in Common Lisp with a tolerance of one (you can see function "dotest") and I thought it was sufficient.

my solution does not pass some random tests because of this issue

I will introduce "double-float".

OK. Length tested!

Agree.
Could be interesting to run some perfomance tests.
Besides smth like String.splitAsStream might be handy.

CommonLisp: The following line should be added to the solution and test code:

(setq *read-default-float-format* 'double-float)

As I understand, CommonLisp uses single precision floating-point numbers by default. Single precision floating-point arithmetic may yield inaccurate results. For example, my solution does not pass some random tests because of this issue.