However, when the function is not expected to return data then it makes sense use the error status as the return value.

Well then I would assume in most cases that it would be 0

If that's the case then why do we really need to set it to anything? If it's not expected to return data then as long as one checks for @ERROR and does not find an error then it should have worked, otherwise regardless of what caused the error it would be captured in the EXIT @ERROR code.

Also in your example by using the NOT operator forces one to use KiXtart 4.50 or newer (which is okay )

But as I view it if no data is expected why would you check for data? That's like expecting to really see the Tooth Fairy when you know it's not there.

Function ChangeVLKey($VOL_PROD_KEY)
Dim $obj, $objects, $result
$objects = GetObject("winmgmts:{impersonationLevel=impersonate}").InstancesOf("win32_WindowsProductActivation")
For Each $obj in $objects
$result = $obj.SetProductKey($VOL_PROD_KEY)
Exit Val('&' + Right(DecToHex(@ERROR), 4))

Here we simply exit with the ERROR if anything caused one during that processing which we didn't expect data.

I assume from your point of view that well we would see the error and know that something went wrong, but I'm thinking the opposite in that for a function that does not return data, I won't go looking, I'll only look for an ERROR

Regardless of outcome here I think it has been a good discussion on the subject.