SCPlugin has struggled to stay functional on current MacOS for a number of years. The reason? I am quoting another developer (Abracode) here:

Snow Leopard does not support contextual menu plug-ins in 64 bit applications

Apple removed native support for contextual menu plug-ins in Mac OS 10.6 in 64 bit mode and replaced it with services items.

Even if the contextual menu plug-in is 64 bit, the applications will not load it.

Almost all, if not all Apple applications shipping with Snow Leopard run 64 bit by default, including Finder, so your contextual menu plugins will not work.

Not happy about it? Let Apple know: Mac OS X Feedback

[...]

More technical discussion:

In Mac OS 10.6 Apple replaced contextual menu plug-ins with enhanced services, which will show up as contextual menu items. The problem is that the services are static (each item is described in application or service plist) so developers cannot create a service that will dynamically add its own menu items. Also, CM plug-ins analyze the context information to display appropriate menu items or not display at all. With services, it is Mac OS X that makes the decision whether to show the service item or not based on the data types that the given service advertises it can handle.

You can expect some simpler contextual menu plug-ins to migrate to services mechanism for Snow Leopard in the near future. The more complex plug-ins are unfortunately out of luck. It is a big loss for people who learned to rely on existing CMs in their workflow. It will take time for alternative solutions to be developed.

[...]

Jack Repenning, the SCPlugin project owner over at Tigris, has suggested a number of workarounds/solutions.

One is to be a good citizen (as Apple defines and redefines and redefines how apps can and should exist) and switch to using the Services Menu. This would bury the functionality one more level deep, reducing utility/ease/visibility for novices and pros alike), and would further deteriorate SCPlugin's utility, and EasySVN's proposed utility, by not allowing feedback & menu intelligence when presenting the menu's contents (say, displaying different options in the menu, per svn, depending on what file or folder is currently selected). Implementing in the Services menu would mean settling for poorer utility than previous versions of SCPlugin, and is therefore unpalatable within the community.

The other, that I believe he preferred, is to work with Abracode's Shortcuts application to regain intelligent CM functionality. This appears to be akin to traveling down a road similar to unsanity's "haxies," which are generally considered to be impermanent, if clever, hacky system extensions that can break application/OS UI in strange ways, may lead to instabilities, and usually break every time Apple updates the OS.

NomaDesk employs their version of this sort of functionality like a good Apple citizen: via the Services menu during a Finder file selection contextual menu. But DropBox has figured out how to do both badging and inserting themselves into the Finder's contextual menus in a prominent way, as is desired for SCPlugin. So it is possible.

The issue is significant, with potential pre-processing workarounds I am able to discuss further.

~

DropBox's technique (to modify the Finder CM) is to use SIMBL plugins, code injection and Objective-C method swizzling. There are a number of implementations, but this one appears the most promising:

https://github.com/rentzsch/jrswizzle see also: http://www.cocoadev.com/index.pl?MethodSwizzling

This essentially swaps the default implementation for your own implementation, which (ideally) will call the default implementation at some point.

Of course, one would need to figure out the method names used by the Finder to deploy their contextual menus.

If they follow their own naming conventions,

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MenuList/Articles/DisplayContextMenu.html#//apple_ref/doc/uid/TP40004968-SW1

...the method names would be "defaultMenu" and "menuForEvent" ... but don't count on it.

It's conceivable, but neither fun nor allowed. And the bad news for badging, is that there doesn't seem to be a non-hack solution route http://scplugin.tigris.org/ds/viewMessage.do?dsForumId=1522&dsMessageId=2629743 and essentially each OS Version will need a unique, hacky solution to achieve the same effect.

Acquiring methodologies: http://www.culater.net/wiki/moin.cgi/CocoaReverseEngineering

In the meantime...

Going about with Services coding, just amassing resources regarding this route for future optional bravery. Icon badging is still an outlier, and I'm looking for a solution.

~

Now the good news. Apple Documentation pertaining to other, new OS X-specific implementation opportunities, requirements and challenges:

Introducing Blocks and Grand Central Dispatch
Building with Blocks in C and Objective-C
Managing Concurrency with NSOperation
Cross-Platform Development
Concurrency Programming Guide
Core Foundation Plug-Ins