Recursive often beats for-loops, but I didn't expect it which such a long function name, so I didn't bother. Well done.

This tries to solve some of the mentioned issues in the Discussion section, as well as an issue with random functions that are not derivable.

Factor translation random test seem to introduce evaluation of expressions with incorrect results
E.g. input "(^ 1 (^ (+ (exp -1) (^ (- (* 0 x) x) 1)) 1))"
My code's result (which I already adapted to "simplify" (- 0 e) into (* -1 e) which the kata description already doesn't require):
"(^ 1 (+ (exp -1) (* -1 x)))"
random test report:

Valid Expression: Test Passed
Result expression:
(^ 1 (+ (exp -1) (* -1 x)))
was found incorrect when compared to reference solution with x = -9:
(ln 1)
Result expression:
(^ 1 (+ (exp -1) (* -1 x)))
should be simplified to:
1

Apart from the forbidden simplication (^ 1 e) into 1, why does the test evaluates (^ 1 (+ (exp -1) (* -1 x))) to (ln 1)??

Such an introduction of seemingly random appareances of (ln constant) occur regularly.

Another example:

Testing: (^ 1 (sin (^ -5 (+ x (sin (- 0 1))))))
Valid Expression: Test Passed
Result expression:
1
was found incorrect when compared to reference solution with x = 4:
(ln 1)

Factor translation test require optimizations in simplification which are strictly forbidden in the Kata description.
E.g.

Testing: (ln (^ 0 (/ x (exp (/ (sin x) (* 2 -4))))))
Log
"(/ (^ 0 (/ x (exp (/ (sin x) -8)))) (^ 0 (/ x (exp (/ (sin x)..."
Valid Expression: Test Passed
Correct derivative: Test Passed
Result expression:
(/ (^ 0 (/ x (exp (/ (sin x) -8)))) (^ 0 (/ x (exp (/ (sin x) -8)))))
should be simplified to:
0

The kata description explicitly has:
"In addition to returning the derivative your solution must also do some simplifications of the result but only what is specified below."

Factor translation (sample) tests throw error on resulting expressions that are functional equivalent due to commutative properties.
E.g. "(* 2 x)" passes the test, but "(* x 2)" doesn't, whereas it should.

this fork is slower

C translation does not report actual value on failure for sample tests.
The expression (prime_stream_next(stream)) == (2) is false.

Prototype should not use const int, that makes no sense at all.

Nope, still same issue

Invalid C solutions that don't take into account stretching of the rubber band incorrectly pass all tests.

Duh! How did I miss that! Good find

Because of the each bit in n part; 11 is not represented as 1011 for each bit in n, but rather as 0..0001011 (depending on size of int).

Thanks for forking! It's shorter, but I just wanted to demonstrate how compilers pool string constants...

really nice!

LOL! It takes 15+ seconds to compile this in Agda