I would oppose the general disemination of the "Get Name of Class.vi" without a lot of caveats. Specifically, I'd be tempted to name the VI "Get Name of Class in a highly inefficient but generic manner good for probes but inappropriate if you are really writing a by-name-lookup object hierarchy.vi" ;-)
Here's the deal: This VI flattens your entire object data to a string. That's not cheap and it gets even more expensive as the object carries more data.
If I am really writing a hierarchy where I expect to do name lookups -- like for database storage type systems -- as part of my actual runtime code, I'm going to add a dynamic dispatch method to the root class called "Get Class Name.vi" and override that at every level of the hierarchy to return a string constant. This avoids the memory allocation and performance hit of the flattening to the string (indeed, if all goes as planned, in 2013's compiler, it will avoid any memory alloc entirely as long as the returned strings really are constants). This solution is what is used in C++.
Using any sort of reflection API to get this information in C# is less efficient than adding the "get class name" method. As far as I know, nothing beats adding this to your class definition. We don't do it for all classes generally because it extends the dispatch table with a feature that most classes do not need.
The class-to-path function that is in the palettes today is mostly to support scripting and debugging type work. Can you find a way to address these concerns in the VI's icon, name and documentation?
Actually, a few days ago I was looking at the Class Library Refnum API to see if it could help me with another idea I have for a useful Object VI. One could do some interesting stuff, but unfortunately Class Refnums don't work on RunTime so one can’t put anything built on it in an exe.
You must be using an old version of LabVIEW. They started working in RunTime in LV 2010. I would NOT recommend using them -- they are VERY slow, because they aren't meant to be used in production code (they instantiate entire projects behind the scenes because they assume you're getting one of these references in order to do manipulation of VIs into or out of libraries or to query about project layout stuff). They should be used for scripting and tools work, not for the actual work of your application. The only reason that they're in the runtime engine is someone wanted to be able to do reflection of projects from TestStand without needing the full development environment.
A couple of renaming suggestions:
"Is Default.vi" ---> "Is Default Value.vi" (just seems clearer to me and leaves namespace open for other "Is Default..." type VIs in the future)
"Same or descendant class.vi" ---> "Is Same or Descendant Class.vi" (use of Is to be consistent with other VIs that primarily return a Boolean; also fixing capitalization to match others)
"Fully Qualified Class Name.vi" ---> "Qualified Class Name.vi" (the Fully is redundant and the shorter name gets more useful info into the palette display)
"Class Name.vi" ---> "Class File Name Without Extension.vi" (the class name is defined throughout LV as either the file name or the qualified name. This makes it clear what is being returned. Again, I wouldn't ship this VI myself, but if you do include it...)
> Putting these VIs in LabVIEW Data would be fine, though that library is quite large already
Can you add them to a subpalette of the "Cluster, Class & Variant" palette? I don't know what ability you have to add to the built-in palettes of LV, but that would seem to me to be the right place for them.