I did this kata in Kotlin. And I would suggest to remove this kata from the Kotlin katas or modify it.
Kotlin goes a great length to be a typesafe language, to reduce an array to Any so that it is possible to have different types in this array, should be prevented at all cost (in Kotlin).
This kata is a level 7 kata and is done from a lot of "Kotlin-Beginners", they could think that this is a good practise (in Kotlin).
Yes, there are other languages, in which you can put everything in an array, but you should not do this in Kotlin.
Instead of using an Array of Any I would suggest to use an Array of String as input.

Sorry that is not best practices, there is a formular for this problem, which is much more efficient.

Yes, that is an improvement, but don't stop there, v is volume. And there should be some spaces to structure the code logical

exactly one of the two expressions evaluate (sic) to true, false otherwise

( my emphasis )

Description is ambiguous.

I don't think so. If you just have one exit point, it often leads to additional variables and complicatet if-else-if-statments. It also invites to do everything in one method. The result is unnecessary long menthods, which are hard to read.
I think it is good practice to leave a method, when the job is done.

I agree with the first comment, that this is no good practice. And I agree that if-else-if-constructs are also no good practice. But as you can see in the frist solution, the else is not even necessary. The result is very easy to read code. You haven't to be a programmer to understand that code. The point is you don't need to get used to it, but to chained ternary operators you have to.

YMMV

I agree with @gotan. It's helping the code to be concise, but not readable.

Agreed. This solution only works because the cyclical state-change happens to only have 3 states. Rhetorically, how would it look if you had a traffic light with 10 colors?

I would not say, that it is best practice, it is coding conventions. And in the majority of coding conventions the brackets are demanded.
I had to work without brackets and I must say since then the code without brackets is much easier to read.
The main argument is allways, that you may add a line outside the conditional block. In my expierence this never happens. And if it happens your test should fail. And if you have to add lines to a conditional block, it maybe time to refactor a methode which a catchy name.

In my opinion code which is best practice, should be readable. This code could be read better with spaces and variable names consiting of more than a single letter.

Thank you for your answer!
I see it exactly the other way. For me this code is not very readable. For me a reader is a person, which has not done the kata, but has to read the code from someone else.
To understand this, the reader has to keep in mind what t is, what the output will be and to keep track of the nested ternary operator. At this time he does not know how the output is used. Most certainly he has to stop at some point to read it again or think about it.
A more readable solution in my opinion, would be, to ask for the typeof the input and return immediately the response. That would be two simple ifs and three returns. In that case a reader could read from top to bottom without thinking. In my opinion that should be the aim, when ever possible.
Additional the described code could easily be extended or refactored, without getting more complex.
I hope this explanation helps!

It is all about context. If it helps readability why is it bad?