Well after a bit more discussion with Glenn on this subject via MSN (Shawn is never on anymore to group chat on this)

I think it boils down a bit more to what is easier to support / use / test and not so much as always mimicking the KiXtart functions which are not 100% consistent either.

As an example in the manual by Ruud

If Exist()

That just doesn't work with 0 for success so he used positive logic for testing.

Returns:
0 File not found
1 File found



So basically in a nutshell (regardless of how KiX internally handles it)

If you can with reasonable certainty know what error you want returned when the function did not do as you wanted then one would force set the value and not use @ERROR
This is on a case by case basis
When the error is fully unexpected then using the @ERROR makes sense.
Setting a positive logic to a RETURN (when data is not excpected) makes more sense than 0 or @ERROR (imho)
ie.. I would set it to 1 to mean it was successful
and set the exit to 0

If I felt the @ERROR might give better feedback than I would use that. Sometimes though setting a specific error gives a better indication of what the problem is.

I apologize for not seemingly being able to clearly define this subject, but I think I have better grasp of how I want to mabye write future UDFs.