In many cases they aren't "safe" to use, and you can be sure they certainly don't go through the usual QA cycle.

Yup. If it's not documented, it's not supported, even though it might be useful.

(I've filed a bug saying that our whole collection of undocumented commands needs cleaning up.

Note that "cleaning up" in many cases may mean "removing from the system" - a whole *pile* of commands are there solely to provoke the system to do things for testing purposes inside development, for example.

In some other cases, it may mean, making information available to support people, and maybe to end-users, but not necessarily committing to keeping the interface the same henceforth and forever more, world without end, amen.

In other cases, it may mean leaving the command around for now, but not documenting it, because changes to the system in the future may obviate the need for it, at which point we'll remove it.)

Now, I'm not saying mv is dangerous (I don't know the code), but I would not be surprised if it didn't fail to lock certain buffers properly in multiuser operation, or not update the filesystem correctly for CIFS attributes, or any number of other problems.

Actually, "mv" happens to be Pretty Damn Simple - it does a pile of standard WAFL operations to look up the containing directories and then the standard WAFL rename operation (and uses an internal-to-Data-ONTAP(R)(TM)(LSMFT) routine to do it, so it's about 12 lines of code - counting blank linkes and curly braces), so it shouldn't, in theory, cause those problems (and won't do any better at moving stuff out of a snapshot than would a "mv" command on a UNIX box or a "ren" command on a DOS/Windows box; moving stuff out of a snapshot isn't exactly trivial), but...

I wouldn't want to risk the possibility of corruption and/or a crash unless it was an "approved" Netapp command.

...that's definitely the case; undocumented means unsupported and, quite likely, untested, and also means "not guaranteed to stick around forever".