Example tests are unreadable for solvers. They heavily use Preloaded code, which is not available to solvers, and we have to assume behaviour from names. This is not the intent of example tests.

Show the Preloaded code in the description, or at least explain what everything does, or move the code into Example tests ( and also into Submit tests, but that's your problem ), or - much preferred - write more readable code in Example tests. Code duplication is not a ( solver ) problem there; example tests are meant to be readable for solvers, and individual tests should preferably be visible in the window in their entirety, without having to scroll to find definitions of factored out code.

Example test #2 tests sfunctor.test. From the description, it is not clear that sfunctor.anythingButVal should exist, because it does not yet have state.

Either only expect sfunctor().anythingButVal to exist, or specify better that sfunctor.anythingButVal uncalled should return either sfunctor() or sfunctor ( and which one, and possibly why ).

The former option would make more sense IMO.

The same goes for sfunctor.val - the state is initialised on first call; what is the expected value here, and why? ( I don't know if this is actually tested. )

Alternatively, sfunctor could immediately have a default state, which might be overwritten normally on first call. But the initial code indicates this is not how things work.

All Example tests run in a single it. This means I have no clue where this message

TypeError: Cannot read properties of undefined (reading 'val')
    at Context.<anonymous> (test.js:127:25)
    at process.processImmediate (node:internal/timers:471:21)

is coming from.

Separate example tests should run in separate its, preferably identifying the test in the header ( counting would suffice I guess, though I would like to see "inputs" ).

I like the task, but currently the description essentially requires the solver to imply behaviour from examples. You have a Task section which starts with an introductory paragraph, and then just ends? I think you need to move the Notes to the end of the description, and also actually explain what this sfunctor actually is before you start clarifying behaviours. Keep in mind that many solvers will likely have even less of an idea of functional programming than you, and so the term "functor" may very well mean nothing to them.

With a good description, I think this could be a nice task.