So you just unzip it and hit yes when it asks, and it wont break anything, correct?
No. Unfortunately it is not that simple.
Let me start with a bit history. Orbiter started with what is commonly called "XCopy-deployment", meaning that it was "just" a bunch of files in specific directory-structure. As long as you preserve the directory-structure (and of course the file names), you can copy Orbiter to whatever directory you want, and run it. This also means that you can create 2 or more Orbiter "installations" on your machine by simply - well - copying your first Orbiter directory to a second.
The means of transport of this "bunch of files" of course was a ZIP archive, that's why before Orbiter 2010 there was no "official" MSI package. Simply unzipping Orbiter to an arbitrary folder by using the "restore path structure" feature of your ZIP tool was enough to restore the files from the transport medium.
Of course, add-on developers started to use this method, too. So in the early days, you just had ZIP archives, some with the directory-structure resemble that of Orbiter itself, some with flat structure, some with proprietary structuring. Most add-on ZIP-archives came with read-me files (inside the archive) that described the installation procedure. Normally it came down to something like "copy the DLLs into /Modules/, the meshes into /Meshes/ and the configuration into /Config/". Simple as that, but certainly far from "one fits it all".
Nowadays, though, even Orbiter itself has veered off of the "XCopy-deployment" way. Even if there is a ZIP archive alternative to the MSI package, there is still some kind of "installation" process involved: the orbiter.exe of a fresh "extraction" is not the Orbiter executable itself, but a placeholder that runs a prerequisite wizard to get the run-times installed. After its execution, this orbiter.exe changes place with the "real" orbiter.exe in /Install/orbiter.bin.
And so did some add-on developers, too. Most prominently DanSteph is publishing his work wrapped in custom installers. While this really enhances the installation experience for new users, it unfortunately also adds to the palette of installation procedures currently in use for Orbiter add-ons, because there is no "rule" whatsoever.
In addition to this already confusing situation, add-ons often produce collisions with other add-ons, especially if authors do not pay attention to namespaces. I.e.: if add-on A uses a texture "goldfoil.dds" in the /Textures/ folder, and add-on B also uses a file with this name there - but with totally different content - installation order decides which add-on will win and which add-on is corrupted. That's why regulars often coin the phrase "try with vanilla Orbiter first" in debugging situations.
Versioning of add-ons only adds fuel to the fire here: imagine a version 2.0 of a base add-on that changes the base.cfg file to refactor the textures used. While the author takes care about the migration path of his add-on, of course, he might not take into account that another add-on could very well use the same line in that configuration as he was using. Thus his installation advice "remove the line Solpanel under BEGIN_TEXTURES and replace it with SterlingMot" has good chances to blow up the full Orbiter setup.
All the mod enablers mentioned here will also not guarantee avoiding collisions, as they can't inspect the packages and sniff out the intention of the author. They help in organizing the mess, but are certainly no silver bullets.
Being a coder, I personally use a version control system to manage my Orbiter installation. This way I don't have to fiddle with collisions manually, but let the system work out the merger of 2 add-ons. This way I can also host different "environments" or copies of Orbiter, one for historical settings, one for near-future, one for Sci-Fi, and so on. Added value is - of course - the version controlling of my own (and others) source code and/or binaries.
Unfortunately this method is more complex than simple package managers or ZIP archives, so I can't recommend it for newcomers (
yet).
regards,
Face