the main issue is that it may make abuse of the commands far easier.
For mIRC's internal implementation I agree, but with native support, given how easy it generally is to use the native method directly instead, I don't see this as a substantial point.
This would also make the commands behave differently on different IRCds, which would make them inconsistent?
Not inconsistent, just less restrictive. Lots of command behave differently across networks in that respect, even e.g. /msg due to ircd-specific channel and user modes.
In general, I don't think it is mIRC's role to artificially restrict ircd-native commands. You could argue that /omsg and /onotice are mIRC's own, but mIRC is in fact already effectively restricting /wallchops right now, since that is also a native ircu command. Given that /wallvoices is a native ircu command, you may even end up breaking people's aliases/scripts by applying a new ops-only restriction (hypothetically, anyway).
Just to confirm: is it common for voiced users to use /vmsg/vnotice to send messages to all other voiced users on a channel? Even though it is possible to communicate on the channel?
We use it on EFnet #mirc this way, at least. If you view nothing/voice/ops as status levels, it makes sense for each level to have its own means of this-and-upward level communication. Then again ircu applies no such restrictions for its own wallchops/wallvoices commands, which I think is not a great idea either.
Overall, the whole situation is kind of a mess. I think you'll mainly have to decide what you want the commands to be - a thin layer on top of whatever is available or a tightly controlled standard interface. My vote would be for the former, but if you implement the latter, we can always continue to use the native methods of course.
