I think the performance element makes this tough for a 6 kyu kata

In C??
The Description is a bit misleading but the comment in the code says to return NULL. Not sure how it is in other languages.

The me from 3 years ago would think the current me is insane for understanding such a basic crap like linked lists lmao

Because its not intentional error handling as kata is expecting problem solver to do (Out of bounds, invalid index or Empty list). I remember one member who solved problem by submitting "NULL NULL NULL" which got validated by test case but obviously was unintentionally accepted as valid solution.

The description only specifies "an exception" in JS, not a specific one. Why would throwing TypeError be wrong?

In javascript translation, solution throwing TypeError after accessing next property of null is considered as valid Exception, there needs to be validation of Exceptions in test cases.

I was thinking about how I think the solution to this "should" be implemented.
Which in my opinion is without a stack or any other copy of the structure, and without creating any new nodes because that would be unneccessary allocation.

It'd be possible to make a version of this where you have to "check out" nodes and only allow a certain amount to be checked out at a time

# let's say check-out limit is 3

def rev(head):
    # head is already checked out, so free=2

    a = head.next()  # free=1
    b = head.next().next()  # head.next() already checked out, that's free, but head.next().next() is now also checked out
                            # free=0
    # c = b.next  # FAIL! no free capacity
    head.invalidate()  # can now check out another node, free=1
    c = b.next()  # OK! free=0
    stuff = [head] # you can hold on to your severed head if you like but it won't talk

for python at least, invalidate can be called in a destructor so that it happens as soon as their ref counts drop to 0, freeing the solver from the cruft. they could literally be using the same interface, .next and leaving scope and the test implementation could keep count of how many are held

one could provide printing facilities to display all the nodes, stop at cycles, one line per orphaned node eg.

H -> 4 -> 3 -> 2 -> 2
5 -> 2
6 -> 4
currently checked out: H 6 4
you did this or that wrong

as well as having the ability to request a re-run of specific tests to avoid flooding output (imagine test frameworks doing test framework stuff, crazy) - to compensate for that it wouldn't be possible to run locally so at least make it cleanly reproducible. (and/or provide a non-restricted version)

this is the sort of exercise where the solver should be reading the test code to understand what they're asked to do

the comparisons are hidden away in preloaded, not exactly helpful. and the test output also doesn't state what it compares, saying things like "1 should be 3" isn't great and in the case of having returned something it may suggest to the solver that the tests are looking at the returned answer since it is clearly looking at something, and finding something wrong with it.

if the kata is supposed to teach then there's a lot of teaching missing in it, all it gives is a smug remark about a single pass which makes very little sense when it isn't establishing constraints and how the solver is intended to reason about the data structure. it could clearly be stating that it's going to provide a list in the form of a node (or None, ick) and that it then expects to read starting from the same node and find the values to have been reversed. ... maybe the solver isn't meant to understand the problem.

in python there are two Node classes to add to the confusion, of course it doesn't want to mention that there's another in preloaded, that would again be helping the solver understand the situation and we can't have that.

I guess, in past 6 katas of same author it was returning new list, for this one its mutating original list, so I assumed (since its not clear what needs to be done) author was asking for thing it has been asking for past 6 katas, description could be more clear that original list needs to be mutated IMO.

Looking at your solution, you are returning a reversed list, which is not what the description ( clearly, IMO ) asks for.

Not a kata issue. Closing.

Are you returning the reversed list or reversing the list in place?

The description is not very clear, but you have to mutate the list that it passes you. It won't actually check anything that your function returns, it just checks the same head node that it passed to your function in the first place (and each node afterwards), so you have to mutate the list.

This is object head initially points to: Node { data: 1, next: Node { data: 3, next: null } }
This is object I return: Node { data: 3, next: Node { data: 1, next: null } }
How is this not reversed? (error test throws: result should be 3 -> 1 -> null.: expected 1 to equal 3)
(Nodejs, javascript)

This is a draft kata, so you cannot submit solutions to it. I don't know if it was a fully-out of beta kata at one point and then unpublished for some reason, or if it was always a beta kata and it was unpublished for some reason. I suspect that the large amount of open issues probably led to whatever happened though.

I'm getting this error when attempting to submit my Python solution. Please advise

You cannot submit your solution at the moment because the kata is not published.