To a point you're getting into the game of second-guessing the developer intent, and without any secondary information, it's hard to be sure.
But really, it's hard to draw a line between power and security.
For instance, right now I'm in error_handler... Basically, adding a hook to output_error allows a plugin to get data on what error will be shown. However, it can't change anything in that -- whether it be the message or error level. It's pretty much useless, apart maybe for adding a message that says "The error below is normal, don't worry about it."
But if I give plugins the ability to change the error message, they can actually cancel the error itself. Can't they? For instance if I pass a reference to $file, and the plugin replaces it with 'Unknown', voilà, the function just returns without calling anything...
'Oh my'.
Remember, the integration functions were originally for linking SMF to a third party app, so reset_pass makes sense there, because what you're doing is when a user changes their password in SMF, you're flagging a routine in A.N.Other system to update the same user's password there too.
I'd argue in that case, there shouldn't be a need for the value to be byref. Other instances, however, yes it should be a byref, particularly if it seems logical for a third party app to want to modify something before SMF has its wicked way with it.
We're sort of taking that idea and expanding on it, meaning that any original purpose is likely now somewhat irrelevant. For each hook, look at where it is, what local variables are applicable and make a judgement call as to whether it is reasonable and appropriate for third party code (of any kind) to be modifying that. reset_pass is one case it shouldn't be necessary, for example.
There are less than 70 hook calls all in all, so it shouldn't take too long. I'll just rename the hooks for now and I'll let you look into the params call by call if you have time.
