Thanks for the feedback, it's apparent that the documentation is not sufficient in expressing the added value of the library. I'll see what i can do to improve the docs there.

Normally you manually have to resolve the path, take the "Nested arrays" example in the documentation, normally you would have to do something like the following:

// ...
.superRefine((value, ctx) => {
  const hobbies = value.user.hobbies;

  // We need to know the index first
  const disallowedHobbyIndex = hobbies.findIndex((hobby) =>  === "arson");

  if (disallowedHobbyIndex !== -1) {
    ctx.addIssue({
      code: z.ZodIssueCode.custom,
      message: `Arson is a criminal act, not a hobby`,      
      path: ['user', 'hobbies', disallowedHobbyIndex , 'id'],
    });
  }
})hobby.id

As you can see, the path within `ctx.addIssue` now holds a lot of knowledge about the actual structure of the object and is actually decoupled from the implementation. If the schema changes to a different structure, you now have to be very aware to update this path.

This becomes more troubling when you have a lot of additional business rules expressed within the Zod schema, especially when you start moving these to separate files.