This comment saved my day!

"Turn it into a string" seems like the wrong thing to do if you're trying to make code run faster. I assume it gives you a faster equality check via a nice hashcode but it still seems dumb.

Puzzle description: Note that ... some elements may be repeated.

Actual tests: no repeated elements
Model solution: wouldn't work with repeated elements

ಠ_ಠ

It is for C#, at least. The C# translation of this kata should be on that 2kyu kata, not this 3kyu one.

It took me a day to find out how to solve, and an hour to figure out that I had done the same mistake.

Nice. Using the same algorithm as (almost) everybody else, but finding a way to make it nicer by building the answer string as you populate the table, instead of having to backtrack afterwards.
Of course, the downside is that you use more memory, and that it is possible that all the extra string allocations makes this slower than just using ints and backtracing in the end.

Obviously you have to escape the ' or " in your list of possible characters, but don't do what I did and forget to escape the \ too. (facepalm)

My JS solution is a bit of a cheat.

It finds a non-optimal route on e.g. [95,51,56,93] or [75,71,63,92] or [34,17,24,18] but there is apparently no such situation in the fixed tests, only sometimes in the random tests.

It fails to find a route at all on e.g. [94,90,75,92] but again this only sometimes comes up in random tests.

Maybe these should be added to the fixed tests.

Pretty sure this doesn't work in the general case :(

In my case, saying which of the two ways of differentiating tan was expected would have helped.

TBH I'm surprised I didn't run into issues with the ordering of chain/product/quotient rules... or maybe it just didn't come up.