On a broad scope, I'm trying to find a way to take two activate-able objects and link/fuse them so that any scripts on them can interact with each other. This has to be done in a way that you can copy-and-paste multiple copies of them and they will continue to work. In other words, the scripts should not reference a specific object in the gameworld that just happens to be attached to it; it should refer directly to the object it is linked to via that link.

Here is specifically what I'm trying to do. I want to make a chest that has a switch or lever attached to it. The switch will do something to that chest. But I want to be able to copy this chest/switch amalgamation and paste it elsewhere in the game world and have it work just like the first. This means that on the switch, I cannot make an absolute reference to that specific chest, or else the switches on any future copies of the amalgamation will refer to that first chest (which, as far as we know, could be miles away) instead of the chest to which its 3D model is physically "attached."

I'll try to clarify further. Imagine I make Chest 1 and attach Switch 1 to it. (When I say "attach," I just mean that the switch appears to be physically mounted on the chest.) I write a script for Switch 1 so that when activated, it does something to Chest 1. Now imagine that I copy both of these and paste them elsewhere. We will call these Chest 2 and Switch 2. I want Switch 2's script to reference Chest 2 without having to actually change the script at all, so that when I pull Switch 2, it affects Chest 2, not Chest 1. This means that Switch 1 cannot be directly pointing to Chest 1; it has to be pointing to whichever chest it is "linked" to. I don't want to have to re-link every new switch to every new chest. If this is possible, I would like to save the chest/switch amalgamation as its own object or group of objects, so that I can just drag it into the render area from the object library.

I don't know anything about linking, or what links are, or if "linking" is the right term to be using, but hopefully you can understand what I mean from this post. Thanks in advance for your help.

I managed to implement what I wanted to do (it's a flavor of cloud storage involving special Dwemer chests scattered around Skyrim with "upload" and "download" buttons mounted to them), but I had to re-add the script to each button and modify the variables one by one. I would appreciate a solution to this (turning the "chest and two scripted buttons" into a singular, copy/paste-able object).

You can try using the Linked Ref tab of your switch. Try adding a new linked ref, then pick your chest. Then select both your chest and your switch and duplicate them.

I don't have a CK here right now, but if you're lucky then the copied switch will link with your copied chest instead of the original one. You can then access the chest from your switch script by calling GetLinkedRef().

(If you're not lucky, then the copied switch will also link to the first chest - then I don't have an idea, sorry )

Ciao, Muh!

After reading through the terminology on the Creation Kit a little more, I've come up with a better way of wording the question:

Is it possible to make a Base Object comprised of ObjectReferences to other Base Objects? If so, can a specific ObjectReference within this new Base Object have a script that interacts with another ObjectReference in that SAME new Base Object, thereby connecting references to them placed within the game internally (i.e. NOT to each other)?

in geck, there were static collections for this (worked on statics only though), you'd just select the objects, hit ctrl-g and got a new base object.
i'm not sure what happened to them in ck, the object list entry is still there, but neither does it contain anything nor can you create new sc's, at least couldn't find out how

but apart from if and how to make them, they're far less handy than it seems at first anyway:
you get huge objects (problems with room bounds, performance etc). there were big issues with total texture count (and again performance). and they were handled as one object for lighting, so you'd get a texture flicker faster than you could say "texture flicker" with them things.
and you couldn't use anything else but statics (like a light or mstt-fx or whatever) in them anyhow.

in 9 of 10 cases when i thought i might use a sc, it just turned out to be a big pain really.
so i guess they had good reasons to kick them out.

something completely different you maybe could look into though are addon nodes - but i don't really have too much of a clue how these work myself, just know something of the name exists and sounds fitting