Hmmm. Can't you just add static members to your classes, then retrieve the static data via overridable accessor methods?
The issue with that is that every single object must then carry around the virtual function pointers for the correct methods. If four virtual functions are needed to get and set two pieces of static data, then that's four 32 bit pointers you've added to each and every object in your simulation. And it's really inflexible and error-prone. If someone extends your heirarchy but forgets to add the static member or virtual functions, then the system breaks without any error messages or warnings.
Something about this sounds wrong to me. Generally speaking, the most efficient implementation of a class hierarchy will let each instance have one pointer to its class type, which will contain the pointers to the class methods and static members, as well as a pointer to its superclass. Anything not overridden in a subclass should default to the closest parent class implementation, instead of breaking.
So yes, that's four 32-bit pointers added to each
class in the system, but that's a far cry from the massive inefficiency of adding method pointers to each
object in the system. Basically, the compiler already uses something like the flyweight pattern, so creating a second class hierarchy for the methods on top of the compiler's system is a waste of memory, CPU, and effort. If something can't be changed on a per-instance basis, it's not stored on each instance.
Unless, of course, I'm wrong because the particular language or compiler you've chosen to use is completely insane.
There are cases for manually using a flyweight pattern, but they mostly involve sending data through an API that can't handle the class structure of your language, such as GPU or network code. In such cases, you'll need either a (possibly virtual) method to assemble the flyweight structure, a class variable to store it, or both, if you choose to use native classes at all.