OK so I need static variables so other scripts can access them, but the problem is that, apparently, all instances of loaded scripts will change all the static variables in every script, even if you isolate a single script component to set.
is there a Static style of variable that can be shared with other scripts AND have its own value per script instance?
I’m afraid that doesn’t make much sense.
It is either a class variable (class level and shared among all instances of the type and its derived types) or a member variable.
You need to get the reference of a particular instance in order to manipulate its state. There’s nothing in between.
Let me give you a brief summary of exactly what my issue is:
I have several null objects which the active will be toggled on/off based on how close the camera is to them. The camera has a list of these objects and it will check every frame to see if they’re close or far. They have a static variable called “AmIOn” which is either 0 or 1. The camera script pulls these variables to determine whether or not the object is active or not. The problem is those static variables are the same even if I set one to a specific script component.
‘AmIOn’ should be an instance variable then.
First of all you’ll most-likely want to cache the script instances instead of the gameobjects itself.
That would avoid frequent ‘GetComponent<>’ calls.
Then, just iterate the component list and access the ‘AmIOn’ member to operate per instance.
You want to use a public instance variable and GetComponent.
Static was never meant to be used for access the way you are doing it.
Ahhh, why don’t you help to spread love for encapsulation. 
You’ve got to expose the variable for it to be of any use. There is no point to making every member of a class private. And in the Unity context, there is nothing to be gained by properties for the sake of properties.
Plus the OP has barely got his head around basic OOP concepts. Encapsulation can come later.
It wasn’t meant to be thaaat serious. I do get your point tho.
However, since we’re already on it, i’d argue it’s best to encapsulate it, even if there may not be a need for it.
And it’s also one thing beginners of an object-oriented language should get used to as early as possible, because a lot of advanced concepts depend on it. Strictly speaking it’s even what OOP demands, but you know that. 
You may believe it or not, I’ve seen people refusing interfaces because they didn’t see an advantage of “just modelling” a classes exposed interface… They wanted to model state directly, even in real projects. It’s a pity that old Unity tutorials did ignore that alot and you still see it in so many “serious” tutorials, not even a single word is spoken about it, in contrast, sometimes people (indirectly/unknowingly) encourage to use public fields since they’ve never got used to OOP in the first place.
Other reasons, well… root of breaking changes (changed access modifier/obsolation with enforced errors), the usual obsolete warnings (well then you might even end up having getter/setter and direct access, which may behave differently in the worst case), no clean API…
I’m aware you know about all of that, but many of these can be avoided/reduced by starting out the correct way instead of heading the wrong way first.
After all, It’s neither highly optimized low-level code nor realtime applications that we write. 