Unlikely. As I understand it, the mutation history of a class includes mutations in its ancestry. And since a LV class is just a LV library, a change in any owned VI (method) is interpreted as a change in the class itself (even though the class private data might not have changed).
The only things I've found for preventing recompilation in otherwise unrelated code is either building classes into .lvlibp binaries (yuck) or using a source control provider that has a file lock feature. I'm not sure whether the latter increses the eventual likelihood of a corrupted project.
I've noticed another cause of rippling dirty dots in my AF application: All msg classes created by the Message Maker tool have inlining enabled on the Send VI. That means any change to the Send method requires a recompilation of every diagram that calls that method. I'm sure the intention was to reduce call overhead for sending messages, but it's one thing I changed in my copy of the template class to try and reign in the source control nightmare.
